Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: API module; delay sending commands to EvseManager until it is ready #856

Merged
merged 4 commits into from
Oct 1, 2024

Conversation

james-ctc
Copy link
Contributor

Describe your changes

The API module can send commands to EvseManager before the manager has completed initialisation.
When this happens there is a potential for the manager to dereference a null pointer and terminate.

This change holds requests to EvseManagers until they have all responded with ready.

Issue ticket number and link

Checklist before requesting a review

  • I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • I read the contribution documentation and made sure that my changes meet its requirements

modules/API/API.hpp Outdated Show resolved Hide resolved
@james-ctc james-ctc force-pushed the fix/api-hold-startup-until-ready branch 2 times, most recently from 1fc956c to ce2b495 Compare September 5, 2024 15:26
bool notify{false};
{
std::lock_guard lock(evse_manager_mux);
evse_manager_ready--;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes rely on the fact that each EvseManager publishes ready only once (which is currently given). Instead of using a counter that counts down you could actually check for each EVSE individually (e.g. by using a map).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Pietfried updated the approach so that an EVSE manager can be ready multiple times and not cause an issue.

@@ -269,12 +269,16 @@ void API::init() {
std::vector<std::string> connectors;
std::string var_connectors = this->api_base + "connectors";

evse_manager_ready = this->r_evse_manager.size();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency reasons I would explicitly use this here since it's been used everywhere else too

Suggested change
evse_manager_ready = this->r_evse_manager.size();
this->evse_manager_ready = this->r_evse_manager.size();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this-> is commonly needed for lambdas. Elsewhere this-> should not be added unless is is actually required.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I just think it might be better to have a consistent style and this has been used throughout this file to refer to class members not just in lambdas

@@ -192,6 +193,12 @@ class API : public Everest::ModuleBase {
std::vector<std::thread> api_threads;
bool running = true;

std::condition_variable evse_manager_cv;
std::mutex evse_manager_mux;
std::int16_t evse_manager_ready{0};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be cleaner to use a bool instead of an integer here since this would better reflect the intent. I also think I would make an explicit check in the cpp file like so:

evse_manager_ready = this->r_evse_manager.size() == 0;
Suggested change
std::int16_t evse_manager_ready{0};
bool evse_manager_ready{0};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r_evse_manager.size() will never equal 0.

  evse_manager:
    interface: evse_manager
    min_connections: 1
    max_connections: 128

If there are 10 EVSE managers then r_evse_manager.size() == 10
evse_manager_ready is set to 10 and decremented when a manager becomes ready.
evse_manager_ready being 0 or less means that at least 10 ready messages have been received.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright :) then I must have misunderstood how this variable works

@james-ctc james-ctc force-pushed the fix/api-hold-startup-until-ready branch 2 times, most recently from 8c4e6e3 to 1c00ddc Compare September 17, 2024 11:38
@james-ctc james-ctc force-pushed the fix/api-hold-startup-until-ready branch 4 times, most recently from 875ade3 to 31e76aa Compare October 1, 2024 09:43
@corneliusclaussen corneliusclaussen added the include-in-release Tag that this PR should be included in the current merge window for the upcoming release if possible label Oct 1, 2024
@james-ctc james-ctc force-pushed the fix/api-hold-startup-until-ready branch from 31e76aa to 8f4430c Compare October 1, 2024 11:02
@james-ctc james-ctc merged commit c26999c into main Oct 1, 2024
9 checks passed
hikinggrass pushed a commit that referenced this pull request Oct 7, 2024
…ady (#856)

* fix: API module; delay sending commands to EvseManager until it is ready

Signed-off-by: James Chapman <[email protected]>

* fix: allow for 128 EvseManagers

Signed-off-by: James Chapman <[email protected]>

* fix: approach updated to allow multiple `ready` events from the
     same EVSE manager

Signed-off-by: James Chapman <[email protected]>

* fix: update to latest main and fix compile/merge issue

Signed-off-by: James Chapman <[email protected]>

---------

Signed-off-by: James Chapman <[email protected]>
@james-ctc james-ctc deleted the fix/api-hold-startup-until-ready branch October 11, 2024 07:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
include-in-release Tag that this PR should be included in the current merge window for the upcoming release if possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants