Skip to content

fix(logs): stop requiring a human subject on actorless runs - #7220

Merged
TheodoreSpeaks merged 2 commits into
stagingfrom
fix/log-regression
Aug 28, 2026
Merged

fix(logs): stop requiring a human subject on actorless runs#7220
TheodoreSpeaks merged 2 commits into
stagingfrom
fix/log-regression

Conversation

@TheodoreSpeaks

@TheodoreSpeaks TheodoreSpeaks commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Summary

Scheduled, webhook, and public-API runs are actorless by design — no human behind them. Since #7190, execution-core.ts only sets executorDelegationOrigin.subjectUserId when the run's principal resolves to a sim_user, so the executor delegation for those runs carries no subject. Every use case downstream that called requirePrincipalSubjectUserId then threw PrincipalSubjectUserRequiredError, which isn't an OrchestrationError and surfaced as an opaque 500.

The reported symptom was Logs — logs_get, logs_get_run_details, and logs_get_execution returned Failed to fetch log for every scheduled run while logs_query kept working — but the same break hit several domains at once.

Authorization for an actorless caller was never the problem and is unchanged. workspace-authorization.ts authorizes those callers on the workflow running a deployment, with no userId involved; that's exactly why the query tools kept working. What broke was code treating the userId as required when it was doing something else entirely. Each site now treats it as what it actually is:

Domain What the userId actually was Treatment
Logsread-log-detail, read-execution-snapshot Attribution for large-value materialization and secret projection. The read path never writes, so LargeValueStoreContext.userId is already optional and unread. Resolved optionally; viewerUserId optional through fetch-log-detail and hydrate-child-traces
Tablesrows.ts A tables-v2-api feature-flag dimension Resolved optionally — a missing user resolves the admin clause to false with no query, so the gate only ever narrows
Credential groupscreate-invite-link created_by, a nullable on delete set null column An actorless run issues an unattributed link rather than being refused. send-invite reuses the subject its own guard already resolved
MCPexecute-tool, use-cases Genuinely load-bearing: the stored credentials presented to a third-party server, plus the permission-group gate Preserves pre-existing behavior — see below

MCP

This one is a real identity, so it preserves what was already happening rather than changing it. Before these tools moved in-process, the executor minted an internal token from ExecutionContext.userId and the MCP route ran as that user; the intermediate version passed the same value as subjectUserId. An unattended run has therefore always reached MCP as the execution actor.

That value is now passed explicitly as executionActorUserId instead of arriving implicitly, and is documented for what it is: for a schedule, webhook, or anonymous public-API run the actor is the workspace system actor resolved during preprocessing — the billing payer, not the workflow's author. A principal that names its own subject always wins, so this can't be used to nominate someone else's credentials, and it is not an authorization input.

An external_user webhook subject falls back too, deliberately: it is a real identity but never a Sim user, so it has no Sim credentials of its own, and those runs have always connected as the actor. Refusing them would break working workflows over a boundary the old path never drew.

Supporting changes

  • @sim/auth gains resolvePrincipalSubjectUserId, with requirePrincipalSubjectUserId reimplemented on top. The resolve/require pair makes the choice visible at each call site — picking require where resolve was correct is what caused this.
  • New identity-faults.ts centralizes the identity-error classification that was copy-pasted across 8 internal tool handlers: PrincipalSubjectUserRequiredError → 403 naming the cause, and a now-typed ExecutorDelegationOriginRequiredError → 401 (it was a bare Error, so a request with no execution context fell through to a generic 500). Each handler keeps its own response envelope.
  • New check:actorless-executor-operations audit keeps this class visible instead of waiting on a canary: it resolves operation policies through spreads and same-file factories, fails closed for lib/internal/** and for shared use-case factories in executor-admitting domains, and requires // actorless-unsupported: <reason> on the 14 sites where a person genuinely is required.

Known gap / follow-ups

  • An unattended run reaches a third-party MCP server as the workspace billing payer. That is pre-existing and preserved here on purpose; the real fix is a workspace-level MCP identity, which is a product decision rather than part of a regression fix.
  • A cheaper refinement: the user is only strictly required for authType === 'oauth' servers. headers (the DB default) and none need no person unless the config references a personal env var, and resolveMcpConfigEnvVars runs with strict: true so a missing var throws rather than silently sending an empty header.

Type of Change

  • Bug fix

Testing

Tested manually. bun run type-check, bun run lint:check, check-block-registry, and bun run check:audits (39/39, including the new audit) all pass. 434 test files / 4807 tests pass across logs, mcp, credential-groups, tables, internal, and auth.

New regression coverage: the actorless path at the readLogDetailUseCase boundary (exercising the real authorization path, not a stub), in hydrateChildTraces, in readLogDetail, for an unattended run and an external-subject webhook reaching MCP as the execution actor, for an authenticated subject taking precedence over it, for the 403 and 401 identity-fault mappings, and fixture-driven tests for the new audit script.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

@TheodoreSpeaks
TheodoreSpeaks requested a review from a team as a code owner August 28, 2026 18:20
@vercel

vercel Bot commented Aug 28, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Aug 28, 2026 6:48pm

Request Review

@greptile-apps

greptile-apps Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR separates optional human attribution from authorization for actorless workflow runs while retaining explicit user requirements for person-scoped operations.

  • Allows scheduled, webhook, and subject-less API executions to read logs and create unattributed credential-group invitation links.
  • Preserves user-bound MCP credential selection by passing the trusted execution actor explicitly.
  • Centralizes internal-tool identity-fault classification and adds an audit for executor operations that still require a human subject.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
packages/auth/src/principal.ts Adds optional subject-user resolution and implements the existing required resolver on top of it.
apps/sim/lib/logs/fetch-log-detail.ts Propagates an optional viewer identity through log materialization and child-trace hydration.
apps/sim/lib/logs/execution/hydrate-child-traces.ts Allows actorless child-trace hydration while retaining workspace and publisher-policy checks.
apps/sim/lib/mcp/application/authorization.ts Resolves MCP’s credential user from the verified principal first and otherwise from the trusted execution actor.
apps/sim/lib/internal/tool-operations/identity-faults.ts Centralizes unauthenticated and missing-human-subject error classification for internal tools.
scripts/check-actorless-executor-operations.ts Adds a static audit requiring executor-admitting operations to resolve identity optionally or document why actorless execution is unsupported.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Workflow trigger] --> B[Verified principal]
  B --> C{Human subject present?}
  C -->|Yes| D[Use subject for attribution]
  C -->|No| E[Continue actorless-capable operation]
  E --> F[Authorize from deployment delegation]
  E --> G[Use trusted execution actor for MCP]
  C -->|Required by operation| H[Return explicit identity-required response]
Loading

Reviews (3): Last reviewed commit: "fix(mcp): keep unattended runs connectin..." | Re-trigger Greptile

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 41 files

Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic

Comment thread apps/sim/lib/mcp/application/execute-tool.ts Outdated
Comment thread apps/sim/lib/internal/mcp/execute-tool.ts Outdated
Comment thread apps/sim/lib/mcp/application/authorization.ts Outdated
Comment thread apps/sim/lib/internal/tool-operations/identity-faults.ts
Scheduled, public-API, and subject-less webhook runs carry no user on their
principal. Several use cases resolved one with requirePrincipalSubjectUserId
where the user was only attribution, so those runs failed with an opaque 500.

Authorization for an actorless caller comes from the workflow running a
deployment, never from a userId; each site now treats the user as what it
actually is.
@TheodoreSpeaks

Copy link
Copy Markdown
Collaborator Author

@greptile

Restores the identity MCP used before the Logs and MCP tools moved in-process:
the executor minted an internal token from ExecutionContext.userId and the MCP
route ran as that user, so a schedule, webhook, or public-API run has always
reached MCP as the execution actor.

Names it for what it is rather than implying it is the workflow's author, and
documents that a workspace-level MCP identity is the real fix. Also types the
missing-execution-context error so it is answered as unauthenticated rather
than falling through to a generic 500.
@TheodoreSpeaks

Copy link
Copy Markdown
Collaborator Author

@greptile

@TheodoreSpeaks
TheodoreSpeaks merged commit 03a76b8 into staging Aug 28, 2026
32 checks passed
@TheodoreSpeaks
TheodoreSpeaks deleted the fix/log-regression branch August 28, 2026 18:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant