[lin-snow]

Gives an LLM invocation a per-request first-token budget: the daemon forwards it to the plugin, which enforces it in the process holding the provider connection, and the daemon backs that up with a gate of its own for the case where the plugin cannot act.

Today a slow provider is bounded only by PLUGIN_MAX_EXECUTION_TIMEOUT (10 min, global). A latency-sensitive caller that needs a first token within seconds has no way to say so, and can only infer a stall from transport timing.

The plugin SDK side is langgenius/dify-plugin-sdks#384. Enforcement belongs there because it is the only form that works in every runtime: under serverless the plugin is reached by a single one-way HTTP POST, so the daemon has no channel to stop an in-flight invocation at all.

What changes

first_token_timeout on RequestInvokeLLM (seconds, omitempty). Forwarded to the plugin in the request payload — no new event type needed for the budget itself.

Two-phase gate in baseSSEService. Before the first output-carrying chunk the handler runs on first_token_timeout + ε; after it, back to PLUGIN_MAX_EXECUTION_TIMEOUT. The daemon sees frames, so this is exact — no dependence on header-flush timing or on there being zero bytes before the first token.

ε is max(250ms, 5% of budget). It is not a second opinion on the budget — a fallback has to be looser than the thing it backs up, or it fires first and the plugin never gets to release the provider connection. This gate is what catches an old plugin, or one whose runtime cannot interrupt a blocking read.

Envelope frames don't count. LLMResultChunk.CarriesFirstToken() looks for non-empty content or a tool call, so a provider that opens with an empty role delta and then stalls is still caught. The SDK applies the same rule to the same stream a hop earlier; the two have to agree, or one stream is judged differently at each layer. Other response types have no such method and count every chunk, so no other endpoint changes behaviour.

Streaming only. With stream: false there is one frame and it arrives when generation is done — enforcing there would silently turn a first-token budget into a total-time budget. Polling inherits the rule via RequestStartPolling.

Typed error frame on timeout: error_type: FirstTokenTimeoutError, with the budget and enforced_by: plugin_daemon in args.

cancel in-stream event. When the response stream closes without the plugin having settled it (end/error), the daemon now tells the plugin to stop. Previously a client disconnect only tore down the listener and deleted the session — the plugin ran its provider call to completion, so an abandoned request kept burning a provider connection and a retry doubled load on an already-slow provider.

plugin_time_to_first_token_seconds, so an operator picking a budget has something to pick it from.

Two fixes that fall out

Making abort-mid-stream a normal path rather than a rare one exposed two pre-existing bugs, both fixed here:

• writeData was reachable concurrently from the reader goroutine and the timeout branch; -race flags the write to gin's response writer. Now serialized.
• onCompletion could fire twice when the stream ended after a timeout or client disconnect, driving plugin_invocations_active negative. Now once.

Compatibility

Every combination degrades toward "looser but still bounded", never unbounded and never a false kill:

caller	daemon	plugin SDK	behaviour
old	new	any	no budget sent → global timeout, as today
new	new	new	exact gate + real cancel + TTFT
new	new	old	exact gate + session torn down; no cancel handling → provider call continues, as today

omitempty means a caller that sets nothing produces a byte-identical payload, so plugin SDKs that predate the field never see the key.

The cancel event is sent unconditionally because nothing on the wire carries an SDK version to gate on (PluginMeta has the manifest version, arch, and the Python interpreter version — not the SDK's). The failure mode on an old SDK is benign and verified: its reader wraps each line in try/except and answers an unknown event with one session-less error frame, which the daemon hands to notifiers that ignore it.

Serverless is excluded from cancel — a write there is an HTTP request, so it would start a second Lambda invocation instead of stopping the first. That runtime already cancels for real through the request context.

Notes for review

• Ordering matters and is pinned by a test: the cancel hook is registered on the response stream ahead of the listener teardown, because the local runtime deletes the session→instance mapping in the listener's OnClose, after which a write returns ErrSessionNotFound.
• The end frame deliberately does not carry a measured TTFT: the success stream is typed LLMResultChunk on both sides, so an extra frame would fail dify's validation. dify can measure its own TTFT — it knows when the first parsed chunk arrives — and the daemon exposes its own view as a metric.
• No codegen changes. The budget is picked up by a type assertion in baseSSEWithSession, so *.gen.go regenerate identically.

Testing

go test ./internal/... ./pkg/... — clean apart from the five Redis-dependent packages that also fail on main without a local Redis (internal/cluster, internal/core/debugging_runtime, internal/core/session_manager, internal/service/debugging_service, pkg/utils/cache). New tests run green under -race, and each commit passes on its own.