fountain's reattach calls exec over plain HTTP and gets 426, orphaning every turn

[lex00]

Found wiring spritzer in as fountain's local data plane (INTENTIUS/fountain-ops#34). Provisioning works beautifully; the turn does not complete, and it stops at one endpoint.

What happens

fountain provisions a sprite, writes files into its filesystem, starts a turn — and then tries to reattach to any existing runtime session. That call fails:

[warning] list_sessions failed during reattach:
  {:api_error, 426, "WebSocket protocol violation: Connection header \"\" does not contain Upgrade\n"}

and the turn is abandoned:

event: stage  reattach  started      {"sprite_name":"fountain-c816d477-e62ef95e"}
event: stage  reattach  interrupted  {"reason":"list_sessions_failed","outcome":"turn_orphaned"}

Reproducible on every conversation, including immediately after a fresh app rollout, on spritzer 0.4.1.

The cause

fountain issues a plain HTTP request against the exec path. spritzer serves GET /v1/sprites/{id}/exec as a control WebSocket only, so the request is rejected with 426 Upgrade Required before any command runs.

The real Sprites API evidently accepts a non-upgraded request on that path (or exposes a separate one for listing sessions) — fountain is a real client and this is what it does.

What I am reasonably confident about, and what I am not

Confident: the 426 is spritzer's, it is the first thing that fails, and it is what orphans the turn. The health endpoint lists GET /v1/sprites/{id}/exec (control WebSocket) and nothing else on that path.

Not confident: exactly which request shape fountain sends, or whether the real API answers it on the same path or a different one. Worth reading Sprites.list_sessions in the Elixir SDK against the upstream API docs before choosing a fix — the answer decides whether this is a missing endpoint or a missing non-WebSocket mode on an existing one.

Why it is worth fixing

Everything up to this point already works, which is what makes it frustrating rather than fundamental. spritzer accepts the create, and fountain writes a real payload into the sprite filesystem — its skill doc and a /home/sprite/.env with a scoped token and conversation id. The emulator is one endpoint away from carrying a fountain conversation to a completed turn.

That is the difference between "the local deployment provisions a sandbox" and "the local deployment runs a conversation", and it is the last thing standing between fountain-ops and an offline loop a beginner can watch work end to end.

Not asking for an agent runtime — the echo-back interpreter is fine and the caveats are documented downstream. Just for the turn to be able to finish.

[lex00]

The 426 is fixed in #19. Verified against a real fountain deployment on k3d with that build swapped in — and it is necessary but not sufficient, so this issue should stay open. Here is what is actually behind it.

The failure moved one step

before:  reattach interrupted  {"reason":"list_sessions_failed"}   # the 426
after:   reattach interrupted  {"reason":"no_active_session"}

And fountain's log now shows the real cause, which the 426 was hiding:

[warning] Title generation failed for conv ...: :no_credentials
[error] GenServer {Fountain.ConversationRegistry, "..."} terminating
** (stop) exited in: GenServer.call(#PID<0.4105.0>, {:write_stdin, "say hello"}, 5000)
    ** (EXIT) normal
    (fountain 0.3.0) lib/fountain/conversations/conversation_server.ex:1228:
      Fountain.Conversations.ConversationServer.kick_turn/4

What fountain is doing

It opens the exec socket for the runtime command, and then writes the prompt into it as stdin. spritzer's interpreter runs the command to completion and closes, so by the time the write_stdin lands the process has already exited normally — and the conversation server crashes on a call to a dead pid rather than getting an error back.

So exec being one-shot is the blocker. Everything spritzer holds — the sprite, the filesystem, the checkpoints — is fine; it is the session lifetime that does not match what a client with an interactive runtime expects.

The decision, which is yours rather than mine

Hold the exec session open until stdin EOF, instead of exiting as soon as the command produces its output. Concretely: for a command the interpreter does not recognise, keep the socket open, accept streamStdin frames, echo them back on streamStdout, and only send streamExit on streamStdinEOF or close.

That would let a fountain turn complete. The reply would be spritzer echoing the prompt, which is exactly what an emulator should produce and what the downstream docs already say a local conversation proves.

I have not done it, for two reasons:

• It changes exec semantics for every client, not just this one. The current contract — run the scripted command, write output, exit — is a real contract that chant's Fly lexicon activities depend on, and echo/cat/rm should almost certainly keep exiting immediately.
• "Unrecognised command becomes an interactive echo session" is a design choice about how far the emulator goes, and fountain's reattach calls exec over plain HTTP and gets 426, orphaning every turn #18 opened by saying this is not a request for an agent runtime. Where that line sits is a call for whoever owns spritzer.

A narrower version that avoids the blast radius: keep one-shot behaviour for the recognised verbs, and only hold the session open when the command is unrecognised and the client has sent no stdin EOF. That keeps every existing client on exactly today's semantics.

Downstream

INTENTIUS/fountain-ops documents this accurately as it stands — provisioning verified, completing a turn not — so nothing there is blocked on a decision here. just verify-conversation fails at exactly this point and says so, which is the gate working.