bug: The FixupController protocol sends edits too early in the lifecycle, leading to overcomplicated client design

[steveyegge]

Cody Version

5.5.9 May 02

IDE Information

IntelliJ IDEA 2022.1 (Community Edition)
Build #IC-221.5080.210, built on April 11, 2022
Runtime version: 11.0.14.1+1-b2043.25 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.4.1
GC: G1 Young Generation, G1 Old Generation
Memory: 752M
Cores: 10
Non-Bundled Plugins:
com.sourcegraph.jetbrains (6.0-localbuild)

Kotlin: 221-1.6.20-release-285-IJ5080.210

Describe the bug

This is (hopefully) not a user-facing/user-visible bug. This is a bug in the client protocol that makes it harder to write new clients. It is a race condition that occurs on every Edit Code (or similar) command.

• First, the Client issues a new editCommands/code RPC.
  • It has not returned yet; it's in the process of being sent.
  • At this point we do not have the task ID for the new task.
  • FixupController in Agent creates the Task and gives it an ID.
  • FixupController starts immediately sending didUpdate notifications
    • We don't know what to do with them because we don't have the task ID
• Finally, the outer editCommands/code RPC completes, and we get the ID.

I think the right fix is probably to have FixupController defer any notifications until it has awaited the initial request completing.

Expected behavior

I would expect it to work like this:

• Client issues an editCommands/code json-rpc call
• It returns with the tracking ID for the new task
• Only then, after it returns, do we start receiving events for the new task

Additional context

This will come up again on each new client we write, until it's fixed.

[pkukielka]

Agree with you Steve and proposed course of action sounds right to me.
As a temp improvement I did that: #1459
It improves the situation by obtaining taskId almost immediately (on the first status change) and fixes some problems by the way.