chat: various fixes around queued/steering states

[connor4312]

See individual commits

[Copilot]

Pull request overview

This PR refines chat request queueing/steering behavior, especially around editing flows, by preserving attached context for queued requests and tightening UI/action enablement based on whether the user is editing a sent vs queued/steering request.

Changes:

• Preserve attachedContext when queueing requests and when processing queued requests after (de)serialization.
• Introduce a new context key (chatEditingSentRequest / editingRequestType) to distinguish editing a sent request vs a queued/steer request and use it to gate queue/steer/submit actions.
• Update the queue/steer picker UI to disable the primary action when input is empty and adjust related labels/styles.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/vs/workbench/contrib/chat/common/chatService/chatServiceImpl.ts	Propagates attached context into queued request models and reconstructs send options when dequeuing. Updates queue branching in sendRequest.
src/vs/workbench/contrib/chat/common/actions/chatContextKeys.ts	Adds an editing request type enum + context key used to distinguish editing states for command gating.
src/vs/workbench/contrib/chat/browser/widget/input/chatQueuePickerActionItem.ts	Disables/enables the primary split-button action based on whether the input has text; tweaks labels and registration callback usage.
src/vs/workbench/contrib/chat/browser/widget/input/chatInputPart.ts	Tracks editing state + editing request type via context keys to support updated menu/keybinding conditions.
src/vs/workbench/contrib/chat/browser/widget/chatWidget.ts	Ensures editing flows set the new context key correctly and adjusts send behavior while editing (pending vs in-flight).
src/vs/workbench/contrib/chat/browser/actions/chatQueueActions.ts	Updates queue/steer action preconditions and keybindings based on the new editing request type context.
src/vs/workbench/contrib/chat/browser/actions/chatExecuteActions.ts	Allows submit while editing a sent request (even if a request is in progress), using the new context key.
src/vs/platform/actions/browser/menuEntryActionViewItem.css	Adds disabled styling behavior for the split-button’s primary action container.

Comments suppressed due to low confidence (2)

src/vs/workbench/contrib/chat/common/chatService/chatServiceImpl.ts:790

• The early return when options?.queue is set makes the later if (options?.queue && hasPendingQueue) block effectively unreachable, so processNextPendingRequest() will never be called in that path. This can leave newly-queued requests stuck when there is no in-flight request but there is an existing pending queue (e.g. editing/re-submitting a queued item). Consider restoring the old branching: only queue-and-return when a request is in progress, otherwise enqueue and kick processNextPendingRequest() (or just send immediately) when nothing is currently pending.

This issue also appears on line 779 of the same file.

		if (options?.queue) {
			return this.queuePendingRequest(model, sessionResource, request, options);
		} else if (hasPendingRequest) {
			this.trace('sendRequest', `Session ${sessionResource} already has a pending request`);
			return { kind: 'rejected', reason: 'Request already in progress' };
		}

		if (options?.queue && hasPendingQueue) {
			const queued = this.queuePendingRequest(model, sessionResource, request, options);
			this.processNextPendingRequest(model);
			return queued;
		}

src/vs/workbench/contrib/chat/common/chatService/chatServiceImpl.ts:790

• There are ChatService tests covering queueing while a request is in progress, but this change also affects the case where options.queue is used while no request is in progress but the model already has pending requests (e.g. editing/resubmitting a queued item). Adding a regression test for that scenario (asserting the queued request is processed via processNextPendingRequest) would help prevent reintroducing stuck-queue behavior.

		if (options?.queue) {
			return this.queuePendingRequest(model, sessionResource, request, options);
		} else if (hasPendingRequest) {
			this.trace('sendRequest', `Session ${sessionResource} already has a pending request`);
			return { kind: 'rejected', reason: 'Request already in progress' };
		}

		if (options?.queue && hasPendingQueue) {
			const queued = this.queuePendingRequest(model, sessionResource, request, options);
			this.processNextPendingRequest(model);
			return queued;
		}