Skip to content

Detect silent failure when Preparing returns to Available#14

Open
snabo1988 wants to merge 2 commits intomainfrom
8-treat-preparing-available-transaction
Open

Detect silent failure when Preparing returns to Available#14
snabo1988 wants to merge 2 commits intomainfrom
8-treat-preparing-available-transaction

Conversation

@snabo1988
Copy link
Copy Markdown
Contributor

Detects silent charging failures where a session enters Preparing
but returns to Available without ever reaching Charging.

Such sessions are now classified as failed and trigger diagnostics,
even though no Faulted status is reported.

Manually verified:

  • Preparing → Available => failed
  • Preparing → Charging → Available => not failed

self._sessions[sn.connector_id] = Session(
self,
or_now(sn.timestamp),
sn.timestamp or datetime.now(timezone.utc).isoformat(),
Copy link
Copy Markdown
Member

@knowack1 knowack1 Jan 12, 2026

Choose a reason for hiding this comment

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

I liked or_now :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thanks!
Agreed — using or_now() consistently makes the intent clearer.
I’ve removed the duplicate inline fallback and kept or_now as the single source of truth for timestamps.

session.ended_silent(
sn.timestamp or datetime.now(timezone.utc).isoformat(),

"PREPARING_ABORTED_BEFORE_CHARGING",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

What is the purpose of this string? Indeed it makes sense for session to hold an enum indicating why session was considered as failed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good point.
For now this is intentionally a string, as Issue #8 focuses only on detecting silent failures, not on formalizing failure classification.

Introducing an enum for failure reasons makes sense and is planned as a follow-up (together with automated tests), but I wanted to keep this change minimal and avoid expanding the scope of this PR.

@@ -254,6 +273,7 @@ async def handle_status_notification(self, sn: call.StatusNotification):
session.ended(or_now(sn.timestamp), get_error_code(sn))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

we call get_error_code by function was removed? Does it work?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

You’re right — the helper was missing after refactoring.
I added get_error_code() locally to this module and verified the faulted flow with runtime tests.

@snabo1988
Copy link
Copy Markdown
Contributor Author

All review comments addressed.
Local tests verified for silent failure and faulted flows.

@knowack1 knowack1 force-pushed the 8-treat-preparing-available-transaction branch from f877b58 to 7f91137 Compare January 20, 2026 23:32
from ..engine import Engine
from typing import cast

def get_error_code(sn: call.StatusNotification) -> str:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is there any reason to move functions from bottom to top?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants