[antosubash]

Two background_tasks requests from the gis-data-portal port: tracking can be turned down or off per task, and collaborators on a resource can watch a task's status.

Closes #710
Closes #709

What changed

• Tracking modes (background_tasks: per-task / per-queue opt-out of execution tracking (5 DB writes per task) #710). TrackingMode: full (today), terminal (success, failure and revoked only), failures (final failure and revoked only) and off.
  • The mode resolves from a message header (.set(headers={SM_TRACKING_HEADER: …})), then the task option @shared_task(sm_tracking=…), then the DB setting execution_tracking, which defaults to full.
  • Reduced modes skip the publish and prerun writes, and heartbeat() honours the mode before opening a session.
  • Tenant and owner stamping, context restore and cleanup always run; postrun cleanup now sits in finally.
  • The outbox sweep keeps its failures-only behaviour, now expressed as a mode.
  • The issue says five writes; it is four for a successful task.
• track_publish (DB setting, default true). false removes the publisher-side DB write, and the worker creates the row from the message (owner, tenant, queue, args, resource). Until a worker picks the task up, its status is a 404.
• Admin retries are always fully tracked. The retry reserves a pending row up front, and a reduced mode would never move it on. Review found this.
• Resource-visible status (background_tasks: let resource-policy grants (not just owner/operator) read task status #709). with_task_resource(sig, resource_type=…, resource_id=…) tags a task, and admin retries keep the tag.
  • The status endpoint now allows operators, then (after the tenant check) the owner, then anyone the resource's registered ResourceType policy lets view it, checked with load_authorized.
  • Unknown types, bad ids, missing resources and denials are all the same 404. The DTO is unchanged: resource viewers see status, not arguments, results or tracebacks.
• Migration b31a70971001 on background_tasks@head adds nullable resource_type and resource_id columns with a both-or-neither check constraint. test_migration_graph is updated for the new head.
• TaskFailed is not published for a task in off mode, since there is no row for it to point at; the docs say so.

Verification

• make lint ✓ · make test-js ✓ · make test-py ✓ (6550 passed, 41 skipped) · make migrations-roundtrip-pg ✓ (alembic check: no new operations)
• New tests: every mode × outcome, session-open counts, publish without a DB write, heartbeat, retries and revoke (test_background_tasks_tracking_modes.py); collaborator allowed, revoked share denied, cross-tenant and no-tenant denied, missing resource, DTO secrecy (test_background_tasks_resource_status.py); headers across worker-only tracking and admin retry (test_background_tasks_resource_transport.py); migration roundtrip and constraint (test_background_tasks_resource_migration.py).
• Code review: two passes; the second came back clean. Rejected findings are recorded with reasons.
• No browser QA: no UI change.

https://claude.ai/code/session_01M9neheZZEe3sVpDi2S3zT4

[cloudflare-workers-and-pages]

Deploying simple-module-python with    Cloudflare Pages

Latest commit:	be29a70
Status:	✅  Deploy successful!
Preview URL:	https://32c2e081.simple-module-python.pages.dev
Branch Preview URL:	https://feat-b31-bg-tracking-resourc.simple-module-python.pages.dev

View logs

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
🔒 Security Review	✅ Completed 2026-10-30T22:30:27.377188Z	be29a70	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.