Module sequence_request 

#846: bynk/sequenceModel — the sequence-diagram custom LSP request.

The first custom (non-standard) request in this server: no workspace/*/ refresh nudge exists for it (there is no generic “refresh a custom method” in the LSP spec or in tower_lsp::Client), and none is needed — Tier 1 is on-demand: the client re-issues the request each time the command/lens fires, rather than the server pushing updates.

Two responsibilities live here, out of lib.rs: locating the Handler AST node enclosing a cursor position (by re-parsing the committed snapshot, the same convention identifier_at uses in lib.rs), and the wire shape sent to the client (a plain serde mirror of bynk_ide::sequence::SequenceModel, Span lowered to LSP Range — same convention as SerKey in lib.rs).

Structs

SequenceModelParams

The bynk/sequenceModel request payload — the same two-field text-document + cursor-position shape every other cursor-anchored request in this server uses (HoverParams, SignatureHelpParams, …).

WireAltBlock

WireBranch

WireMessage

WireParticipant

WireSequenceModel

Functions

handler_lens_sites

Every on <kind> handler declaration in text, for the per-handler “Show Sequence” CodeLens. Not index_queries::code_lenses — that walks SymbolKind::Handler sites, which only agent handlers get (bynk-check/src/index.rs: “Service handlers have no per-handler name… so only agent dispatch is covered”); reusing it as-is would silently drop the lens for every service (non-agent) handler, which is most of them. A direct AST walk covers both uniformly.

sequence_model_at

Locate the Handler enclosing offset in text and build its sequence model. info is the owning unit’s cross-context/agent table — None degrades classification to capabilities only (still correct; just unable to recognise agent/cross-context lifelines), which happens for a unit sequence_info has no entry for (a commons file, or one this round never reached because the pipeline bailed before it).

to_wire