feat: dashboard responses re-export shim#1037
Closed
sejori wants to merge 2 commits into
Closed
Conversation
Adds the dwctl-side schema changes for the multi-step Open Responses
orchestration described in
fusillade/docs/plans/2026-04-28-multi-step-responses.md.
Changes:
- response_step_id column on http_analytics + tool_call_analytics
(nullable, partial index), so every upstream HTTP call recorded by
the outlet middleware can be correlated to the response_steps row
that drove it. Mirrors the existing fusillade_request_id /
fusillade_batch_id correlation pattern.
- CHECK constraint on tool_sources.kind documenting the supported set
('http', 'agent') — 'agent' is the new sub-agent dispatch kind that
exercises run_response_loop's recursion path. NOT VALID skips the
full-table scan; existing rows are guaranteed to satisfy the
constraint because 'http' is the only value used pre-migration.
This closes COR-344. Linear-side issues for the dependent Rust
code changes (COR-345 through COR-354) remain open pending the
fusillade and onwards releases (PRs #248 and onwards#185) being
merged and published, after which the FusilladeResponseStore can
be extended to implement onwards' new ResponseStore trait methods,
the transition function and assembly logic can be wired in, and
the RequestProcessor::process dispatcher can be added.
Adds dashboard/src/components/features/responses/ as a forward-looking
home for the planned Responses dashboard described in
fusillade/docs/plans/2026-04-28-multi-step-responses.md. The new
directory currently re-exports AsyncRequests and AsyncRequestDetail
under their planned new names (Responses, RequestDetail), so future
call-sites can import from components/features/responses without
needing to be rewritten when the substantive rename and feature work
land.
The full rename, per-step timeline, recursive sub-agent tree view,
polling for in-flight trees, and response_step_id analytics drill-downs
(COR-355 through COR-360) are deferred until the dependent dwctl PR
ships the GET /v1/responses/{id}/steps endpoint and the
fusillade/onwards crate releases land — there is no live data for those
views to render until then.
Deploying control-layer with
|
| Latest commit: |
7452905
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d0e02f75.control-layer.pages.dev |
| Branch Preview URL: | https://feat-responses-dashboard-shi.control-layer.pages.dev |
Contributor
There was a problem hiding this comment.
Pull request overview
Introduces forward-compatible “Responses” import path for the dashboard while also adding backend schema support for multi-step response analytics correlation.
Changes:
- Add
dashboard/src/components/features/responses/index.tsas a shim that re-exports existing async-requests components under the future “responses” names. - Add a dwctl migration introducing
response_step_idcolumns + partial indexes for analytics tables and constrainingtool_sources.kindto('http','agent').
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| dwctl/migrations/096_multi_step_responses_columns.sql | Adds analytics linkage columns/indexes and constrains tool_sources.kind values for upcoming multi-step responses work. |
| dashboard/src/components/features/responses/index.ts | Adds a re-export shim so new dashboard call-sites can import from the future responses/ path. |
Comment on lines
+41
to
+48
| -- Document and constrain the tool_sources.kind set. NOT VALID skips the | ||
| -- full-table validation scan; existing rows are guaranteed to satisfy | ||
| -- the constraint because 'http' is the only value used pre-migration. | ||
| DO $$ BEGIN | ||
| ALTER TABLE tool_sources ADD CONSTRAINT tool_sources_kind_check | ||
| CHECK (kind IN ('http', 'agent')) NOT VALID; | ||
| EXCEPTION WHEN duplicate_object THEN NULL; | ||
| END $$; |
Comment on lines
+1
to
+4
| -- Multi-step Open Responses orchestration: dwctl analytics linkage and | ||
| -- tool_sources extension. | ||
| -- | ||
| -- See fusillade/docs/plans/2026-04-28-multi-step-responses.md. |
Comment on lines
+36
to
+39
| 'Optional FK to fusillade.response_steps for multi-step responses. NULL for non-multi-step requests.'; | ||
|
|
||
| COMMENT ON COLUMN tool_call_analytics.response_step_id IS | ||
| 'Optional FK to fusillade.response_steps. Set when the tool call originated from a response_steps row rather than the legacy in-process tool loop.'; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Forward-looking shim for the dashboard side of the multi-step Open Responses initiative described in fusillade plan.
Adds `dashboard/src/components/features/responses/index.ts` that re-exports `AsyncRequests` as `Responses` and `AsyncRequestDetail` as `RequestDetail`. New call-sites can import from the planned new path now and not need to be rewritten when the substantive rename + feature work land.
Linear coverage
The substantive dashboard work depends on the `GET /v1/responses/{id}/steps` endpoint shipping in dwctl (one of the deferred sub-issues from #1036), and on the `response_step_id` analytics columns being populated by outlet/dwctl after the fusillade and onwards releases land. There is no live data for the timeline or tree views to render until those are in place. Filed comments on each Linear issue documenting the exact data dependency.
Test plan