[CHORE]: Remove next_run from attached_functions

[tanujnay112]

Description of changes

Summarize the changes made by this PR.

• Improvements & Bug fixes
  • Removed references to the next_run​column
• New functionality
  • ...

Test plan

How are these changes tested?

• Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Migration plan

Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?

Observability plan

What is the plan to instrument and monitor this change?

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the _docs section?_

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[tanujnay112]

• [ENH]: Modified AttachFunction to do 2PC on a new is_ready column #5872 : 2 dependent PRs (#5867 , #5884 )
• [CHORE]: Remove next_run from attached_functions #5871 👈 (View in Graphite)
• [CHORE]: Disable S3heap service and remove nonce-related logic #5866
• [ENH]: Refactor compactor into three chained orchestrators #5831
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[propel-code-bot]

Drop next_run field from attached_functions across DB, API, and services

This PR removes the next_run scheduling timestamp from the attached_functions model and propagates that removal through the entire stack (Go coordinator, Rust client/types, proto definitions, tests, and DB schema migrations). All struct fields, test expectations, protobuf fields, JSON conversions, and SQL queries referencing next_run or next_run_at are deleted. A new Atlas migration (20251114134400.sql) drops the column in Postgres.

Key Changes

• SQL migration 20251114134400.sql drops column next_run from attached_functions table
• Proto message AttachedFunction (and generated client code) removes next_run_at (field tag 12)
• Go coordinator: task.go, create_task_test.go, list_attached_functions_test.go delete all field usages; leftover variable nextRun still referenced when pushing schedule
• Rust: types (flush.rs, task.rs), sysdb client (sysdb.rs), test sysdb mocks updated to remove next_run handling
• DB model (dbmodel/task.go) and coordinator domain models updated to drop NextRun/AttachedFunctionNextRun
• Atlas checksum (atlas.sum) updated
• Extensive unit-test adjustments for removed field

Affected Areas

• go/pkg/sysdb/coordinator/* (AttachFunction flow, list APIs, tests)
• go/pkg/sysdb/metastore/db/dbmodel
• go/pkg/sysdb/metastore/db/migrations
• idl/chromadb/proto/coordinator.proto
• rust/types, rust/sysdb crates
• Generated clients and mocks

This summary was automatically generated by @propel-code-bot

[propel-code-bot]

[BestPractice]

The function_id field is being added at line 718 after updated_at, but this changes the field ordering compared to the original code where it appeared earlier (line 705). While Go struct initialization with named fields isn't order-dependent for correctness, this inconsistency makes the code harder to review.

The original placement (after function_name, before input_collection_id) was more logical since it groups function-related fields together. Consider maintaining the original field order for consistency:

Suggested Change

Suggested change

	id: attached_function.id.0.to_string(),
	name: attached_function.name.clone(),
	function_name: attached_function.function_id.to_string(),
	function_id: attached_function.function_id.to_string(),
	input_collection_id: attached_function.input_collection_id.0.to_string(),

⚡ Committable suggestion

Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Context for Agents

[**BestPractice**]

The `function_id` field is being added at line 718 after `updated_at`, but this changes the field ordering compared to the original code where it appeared earlier (line 705). While Go struct initialization with named fields isn't order-dependent for correctness, this inconsistency makes the code harder to review.

The original placement (after `function_name`, before `input_collection_id`) was more logical since it groups function-related fields together. Consider maintaining the original field order for consistency:

<details>
<summary>Suggested Change</summary>

```suggestion
        id: attached_function.id.0.to_string(),
        name: attached_function.name.clone(),
        function_name: attached_function.function_id.to_string(),
        function_id: attached_function.function_id.to_string(),
        input_collection_id: attached_function.input_collection_id.0.to_string(),
```

⚡ **Committable suggestion**

Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

</details>

File: rust/sysdb/src/test_sysdb.rs
Line: 718

[propel-code-bot]

[CompanyBestPractice]

This migration removes a column from the attached_functions table, which is a potentially unsafe operation. According to our SQL migration guidelines, removing a column requires careful consideration:

1. Backward compatibility: Existing application code still referencing next_run will fail after this migration runs
2. Zero-downtime deployment: If using blue-green or rolling deployments, old instances will crash when the column disappears
3. No rollback path: The ALTER TABLE DROP COLUMN is irreversible without restoring from backup

Recommended approach for safer column removal:

1. First deploy: Stop writing to the column, ignore reads
2. Second deploy (after monitoring): Remove column references from code
3. Third deploy: Run migration to drop column

Alternatively, document that this is a breaking change requiring complete system shutdown during deployment.

Context for Agents

[**CompanyBestPractice**]

This migration removes a column from the `attached_functions` table, which is a potentially unsafe operation. According to our SQL migration guidelines, removing a column requires careful consideration:

1. **Backward compatibility**: Existing application code still referencing `next_run` will fail after this migration runs
2. **Zero-downtime deployment**: If using blue-green or rolling deployments, old instances will crash when the column disappears
3. **No rollback path**: The `ALTER TABLE DROP COLUMN` is irreversible without restoring from backup

Recommended approach for safer column removal:
1. First deploy: Stop writing to the column, ignore reads
2. Second deploy (after monitoring): Remove column references from code
3. Third deploy: Run migration to drop column

Alternatively, document that this is a breaking change requiring complete system shutdown during deployment.

File: go/pkg/sysdb/metastore/db/migrations/20251114134400.sql
Line: 2