Follow-up from #160.
supportsOutboundSync() (packages/outpost/shared/src/sync/capabilities.ts) gates force-sync so the dashboard can't enqueue TRACKER_SYNC jobs for a plugin the worker has no adapter for — those jobs return Plugin "<name>" is not registered, which worker.ts handleFailure retries to maxAttempts and then dead-letters.
The list is static, but registration is additionally conditional on env: initializeSyncEngine() only registers Linear when both LINEAR_API_KEY and LINEAR_TEAM_ID are set. So a deployment missing either has no Linear adapter while supportsOutboundSync('linear') still returns true — the DLQ flood the gate closes by design stays reachable by misconfiguration.
The web app can't just read those env vars: web and worker are separate deployments and their env can differ, so checking locally would be a guess that's wrong in exactly the case that matters.
The real fix is the worker publishing what it actually registered — a SystemConfig row written at boot, or exposing it on the health endpoint. That makes this a natural companion to the /health work in #138, which is already about the worker reporting its own state.
Until then the limitation is recorded in the module doc rather than papered over.
Follow-up from #160.
supportsOutboundSync()(packages/outpost/shared/src/sync/capabilities.ts) gates force-sync so the dashboard can't enqueueTRACKER_SYNCjobs for a plugin the worker has no adapter for — those jobs returnPlugin "<name>" is not registered, whichworker.tshandleFailureretries tomaxAttemptsand then dead-letters.The list is static, but registration is additionally conditional on env:
initializeSyncEngine()only registers Linear when bothLINEAR_API_KEYandLINEAR_TEAM_IDare set. So a deployment missing either has no Linear adapter whilesupportsOutboundSync('linear')still returnstrue— the DLQ flood the gate closes by design stays reachable by misconfiguration.The web app can't just read those env vars: web and worker are separate deployments and their env can differ, so checking locally would be a guess that's wrong in exactly the case that matters.
The real fix is the worker publishing what it actually registered — a
SystemConfigrow written at boot, or exposing it on the health endpoint. That makes this a natural companion to the/healthwork in #138, which is already about the worker reporting its own state.Until then the limitation is recorded in the module doc rather than papered over.