Summary
NetScript 0.0.5 types a worker handler payload while building a job, but erases that payload type before registration and enqueue. An application cannot derive a safe job id -> payload map from the published job definition/registry, and a payload for one job can compile when enqueued for another.
Published 0.0.5 behavior
defineJob(...).payload<TPayload>() narrows the handler payload while JobBuilder is being constructed.build() returns JobDefinition<TId> whose public shape retains id, entrypoint, name, and topic, but no payload type/schema.- The workers service
JobTriggerInput exposes payload?: Record<string, unknown>.
- Trigger-core
enqueueJob<TJobId, TPayload>(job, options) infers the options payload independently because JobDefinition<TJobId> has no payload parameter.
- Generated job registries use
JobHandler<any>, so generation cannot recover the erased payload type.
That means the following application invariant is not expressible using the published types: selecting literal job ID embed-document must require EmbedDocumentPayload, while selecting transcribe-image must require TranscribeImagePayload.
Expected
- Preserve payload type/schema in a shape such as
JobDefinition<TId, TPayload>.
- Generate/export a literal job-ID-to-payload registry/type map.
- Bind
triggerJob and trigger-core enqueueJob payload to the selected job definition/ID.
- Preserve the handler type in generated registration instead of
JobHandler<any> at the application boundary.
- Reuse the same definition for runtime validation, so producer and consumer cannot drift.
Consumer impact
EIS-Chat must temporarily own a small shared job contract to restore compile-time and runtime safety around an otherwise native workersContract + createServiceClient transport. That compatibility seam will be removed when the published registry carries the payload mapping.
Related: #1451 tracks generated job registry operational metadata and handler erasure, but does not cover the job-ID-to-payload contract at trigger/enqueue call sites.
Summary
NetScript 0.0.5 types a worker handler payload while building a job, but erases that payload type before registration and enqueue. An application cannot derive a safe
job id -> payloadmap from the published job definition/registry, and a payload for one job can compile when enqueued for another.Published 0.0.5 behavior
defineJob(...).payload<TPayload>()narrows the handler payload whileJobBuilderis being constructed.build()returnsJobDefinition<TId>whose public shape retainsid,entrypoint,name, andtopic, but no payload type/schema.JobTriggerInputexposespayload?: Record<string, unknown>.enqueueJob<TJobId, TPayload>(job, options)infers the options payload independently becauseJobDefinition<TJobId>has no payload parameter.JobHandler<any>, so generation cannot recover the erased payload type.That means the following application invariant is not expressible using the published types: selecting literal job ID
embed-documentmust requireEmbedDocumentPayload, while selectingtranscribe-imagemust requireTranscribeImagePayload.Expected
JobDefinition<TId, TPayload>.triggerJoband trigger-coreenqueueJobpayload to the selected job definition/ID.JobHandler<any>at the application boundary.Consumer impact
EIS-Chat must temporarily own a small shared job contract to restore compile-time and runtime safety around an otherwise native
workersContract+createServiceClienttransport. That compatibility seam will be removed when the published registry carries the payload mapping.Related: #1451 tracks generated job registry operational metadata and handler erasure, but does not cover the job-ID-to-payload contract at trigger/enqueue call sites.