Couple LongRunningCommandAgentInteractionState with block id#27
Conversation
|
|
||
| /// How the agent is interacting with the current long running command (if at all). | ||
| /// Deprecated in favor of long_running_command_agent_interaction. | ||
| pub long_running_command_agent_interaction_state: |
There was a problem hiding this comment.
should also skip serializing if this is None, no?
There was a problem hiding this comment.
Yea might as well add it now. Technically just need #[serde(default)] once the field is no longer populated
|
|
||
| /// How the agent is interacting with a specific long running command block. | ||
| #[derive(Clone, Debug, Deserialize, Serialize, PartialEq, Eq)] | ||
| pub struct LongRunningCommandAgentInteraction { |
There was a problem hiding this comment.
Rather than adding a separate type and having to deal with migrating from one LRC type to another, I actually think it could be ok to just add active_block_id as a sibling field? Is that enough to determine if the update should be applied (wouldn't block_id as populated by the sharer always be the active block ID)
There was a problem hiding this comment.
then you don't have to deal with a semantic either/or migration for the new field and old field, can just say there is a new field only supported by newer clients?
There was a problem hiding this comment.
The complication with that is that UniversalDeveloperInputContext is a merging of several sources of writes to a shared cache. If we put active block id on this, it would either need to be populated on every source (and probably all of these updates should be guarded on matching block id), or we say it's specifically for the LRC update which is weirder imo.
I think coupling to LRC update is what I want. For this update we need the block id to come from the source of updating LRC state, not the active block id at time of sending UniversalDeveloperInputContext
2 participants
See warpdotdev/warp#12384