Which package(s) are affected?
@aws-blocks/bb-async-job
Describe the bug
To make the queued->processing->complete state transition observable to a client, consumers must hard-code an artificial setTimeout(1500) in the processor. This is a tuned timing assumption, not a guarantee: it races against client/test polling cadence, so the intermediate state can be missed or the transitions can race.
Evidence
document-ingestion-pipeline, preamp batch manual-deploy-20260717-103949-1339. All 3 reps added the delay; 2/3 reps then failed the majority of functional tests (judge 6.0/6.4) while the one that worked scored 82%. Event-driven frameworks on the same task hit ~86%.
Expected
A deterministic way to observe async job state transitions that does not depend on a tuned delay.
Suggested fix
Expose a first-class status/subscription API for job state so intermediate states are reliably observable without injecting processor delays
Which package(s) are affected?
@aws-blocks/bb-async-job
Describe the bug
To make the queued->processing->complete state transition observable to a client, consumers must hard-code an artificial
setTimeout(1500)in the processor. This is a tuned timing assumption, not a guarantee: it races against client/test polling cadence, so the intermediate state can be missed or the transitions can race.Evidence
document-ingestion-pipeline, preamp batch manual-deploy-20260717-103949-1339. All 3 reps added the delay; 2/3 reps then failed the majority of functional tests (judge 6.0/6.4) while the one that worked scored 82%. Event-driven frameworks on the same task hit ~86%.
Expected
A deterministic way to observe async job state transitions that does not depend on a tuned delay.
Suggested fix
Expose a first-class status/subscription API for job state so intermediate states are reliably observable without injecting processor delays