Add support for agent status in handshake process

[sophie-cluml]

Closes: #55

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.12%. Comparing base (98676f3) to head (4b90217).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #56      +/-   ##
==========================================
+ Coverage   70.48%   71.12%   +0.64%     
==========================================
  Files          10       10              
  Lines        1213     1240      +27     
==========================================
+ Hits          855      882      +27     
  Misses        358      358              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[msk]

I believe there’s a conceptual issue with the current implementation. The Status enum defined in this PR is aligned with the Status in the review-database, but this correspondence doesn't seem appropriate in this context.

The Status in review-database is intended to represent the agent’s status from REview's perspective, while the status field in the handshake protocol is meant to allow the agent to report its own status. These are distinct concerns. The agent's status field should reflect only the states the agent can report about itself, and it shouldn’t overlap with REview’s internal representation or database schema.

As far as I understand, this new status field is to differentiate whether the agent is operating in normal mode or minimal mode. If this is still the case, the enum should directly represent those operational states. How the status is stored in the database should remain an implementation detail internal to REview and not be a concern for the agent.

Could you clarify and potentially revise the PR to align the Status enum with the agent's self-reported states rather than the database schema?

[sophie-cluml]

Thank you for very kind comment, the changes are applied.

[msk]

@sehkone, I've got just one minor request for a change, mentioned in my review. Once that's addressed, this PR is good to merge. I'll leave it to you to merge. Feel free to release 0.9.0 if needed.

[sehkone]

@sehkone, I've got just one minor request for a change, mentioned in my review. Once that's addressed, this PR is good to merge. I'll leave it to you to merge. Feel free to release 0.9.0 if needed.

Thanks for the review! Once the requested change is addressed, I'll handle merging the PR and releasing version 0.9.0.

[sehkone]

Since this method name doesn't look like it describes normal status, is Status::Normal relevant here?

[sehkone]

While I may not have the full context, including corner cases, I feel Running serves as a better opposite to Idle than Normal.

[sehkone]

While I may not have the full context, including corner cases, I feel Running serves as a better opposite to Idle than Normal.

Only if the agent is really in the status of running.

[sophie-cluml]

As we discussed in another channel, I modified it to Working, and it was clarified that handshake_incompatible_err is the name of a test method.

[sehkone]

Status::Idle clearly describes its intended meaning. My concern is finding a term that properly represents the other status. While I suggested Running, it implies the agent is actively working, but it should also include the state where the agent is starting to fetch the configuration. For this reason, I am now suggesting Ready, as it encompasses both scenarios: when the agent is working and when it is preparing to work.

[sophie-cluml]

Changes ard done.

[sehkone]

Since @msk's request has been addressed and he delegated the merge to me, I am merging this.