# Upgrade Fastflow Command Polling Index

## Analysis

Fastflow PR `tidbcloud/fastflow#10` was merged into `master` at commit
`7cd7da0d444dcb322feb87b56926bb005192de66`. It adds a generated `has_cmd`
column, an index on `(worker, has_cmd)`, and changes command polling to use the
indexed column.

The dataflow repository currently pins all Go modules to
`github.com/tidbcloud/fastflow v1.0.0-20240122`. The merged fix is released as:

`v1.0.0-20260720`

| Area | Impact | Verification |
| --- | --- | --- |
| Root dataflow module | Workflow workers run the optimized query and startup migration | Workflow, backup model, and bootstrap tests |
| `dataflow-service-ng` | Keeps the independent module on the same fastflow revision | Workflow package tests |
| `dataflow-agent-ng` | Keeps the shared replacement consistent | Module dependency resolution |
| E2E module | Keeps test builds aligned with production modules | Module dependency resolution |

No fastflow imports or APIs change. The upgraded revision is based on the same
fastflow `master` history and preserves DAG cancellation behavior.

## Execution steps

1. Update the fastflow replacement in all four Go modules.
   - Verify every replacement points to the release above.
2. Refresh module checksums through Go tooling.
   - Verify only fastflow-related dependency metadata changes.
3. Run focused regression tests in the root module:
   - `go test ./app/workflow/... ./app/models/backup/impl ./internal/cmd/bootstrap`
4. Compile the fastflow integration packages in `dataflow-service-ng`:
   - `go test ./app/workflow/impl ./app/workflow/action`
5. Verify the replacement metadata in `dataflow-agent-ng` and `test/e2e`:
   - `go mod edit -json`
6. Review the final diff and confirm no unrelated workspace changes are included.

## Risks

- The first workflow startup after deployment runs DDL against `dag_instances`.
  Production rollout must account for the generated-column and index creation
  time on the existing table.
- All workflow replicas share the database. The StatefulSet rolling update
  should keep migration startup sequential, and the migration itself skips
  schema objects that already exist.