Two integration gaps surfaced wiring a plain oRPC Service (eischat) to enqueue jobs on the workers plugin API via the typed SDK client (alpha.18, a multi-plugin workers+streams app).
-
Service -> plugin-API discovery is not auto-wired. createServiceClient({serviceName: workers-api, routerName: workers}) resolves services__workers-api__http__0, but the generated register-services helper only wires ServiceReferences via services.get(name) (plain services). Plugins live in a separate map, so a Service that references a plugin gets undefined and no env var is injected -- only Apps, BackgroundProcessors, and plugin->plugin wire plugin endpoints (via plugins.get + PluginReferences). A Service cannot declare a resolvable reference to a plugin API. Workaround: inject services__workers-api__http__0 by hand. Proposal: allow a Service to declare a plugin reference that the generator wires from the plugins map (like BackgroundProcessors do).
-
The workers-api service does not register USER jobs. GET /api/v1/workers/jobs returns only the plugin built-in workers-plugin-health-check. Our workers/jobs handlers (embed-document, transcribe-image) are present in the generated .netscript/generated/plugin-workers/job-registry.ts and load correctly in the background PROCESSOR (workers/runtime.ts), but are absent from the API SERVICE, so POST /api/v1/workers/jobs/{id}/trigger returns 404 for embed-document (verified against /api/openapi.json -- the route exists; the job id is simply unknown). The bootstrap module (NETSCRIPT_PLUGIN_SERVICE_BOOTSTRAP_MODULE -> services/_shared/plugin-service-context.ts) supplies db/kv/logger/contracts context but does not register job handlers. Note: capabilities/background-jobs.md names the generated registry jobs.registry.ts, while the generator + runtime use job-registry.ts -- a likely path/name mismatch causing the API service to never load user jobs.
Net effect: a Service cannot enqueue a user job through the typed workers client end-to-end without manual endpoint injection AND without the API service loading the user job registry.
Two integration gaps surfaced wiring a plain oRPC Service (eischat) to enqueue jobs on the workers plugin API via the typed SDK client (alpha.18, a multi-plugin workers+streams app).
Service -> plugin-API discovery is not auto-wired. createServiceClient({serviceName: workers-api, routerName: workers}) resolves services__workers-api__http__0, but the generated register-services helper only wires ServiceReferences via services.get(name) (plain services). Plugins live in a separate map, so a Service that references a plugin gets undefined and no env var is injected -- only Apps, BackgroundProcessors, and plugin->plugin wire plugin endpoints (via plugins.get + PluginReferences). A Service cannot declare a resolvable reference to a plugin API. Workaround: inject services__workers-api__http__0 by hand. Proposal: allow a Service to declare a plugin reference that the generator wires from the plugins map (like BackgroundProcessors do).
The workers-api service does not register USER jobs. GET /api/v1/workers/jobs returns only the plugin built-in workers-plugin-health-check. Our workers/jobs handlers (embed-document, transcribe-image) are present in the generated .netscript/generated/plugin-workers/job-registry.ts and load correctly in the background PROCESSOR (workers/runtime.ts), but are absent from the API SERVICE, so POST /api/v1/workers/jobs/{id}/trigger returns 404 for embed-document (verified against /api/openapi.json -- the route exists; the job id is simply unknown). The bootstrap module (NETSCRIPT_PLUGIN_SERVICE_BOOTSTRAP_MODULE -> services/_shared/plugin-service-context.ts) supplies db/kv/logger/contracts context but does not register job handlers. Note: capabilities/background-jobs.md names the generated registry jobs.registry.ts, while the generator + runtime use job-registry.ts -- a likely path/name mismatch causing the API service to never load user jobs.
Net effect: a Service cannot enqueue a user job through the typed workers client end-to-end without manual endpoint injection AND without the API service loading the user job registry.