[v3] feat: add sessionResumedPattern to matching AuthMe's valid_session message

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.

[monikon22]

Follow-up to #57/#60. The fallback there assumes login and sends the command anyway when no login/register prompt arrives — right default, but some servers treat the prompt as proof the player isn't already authenticated some other way, where a silent reconnect is a real failure rather than a stale session.

Adds failOnMissingPrompt (default false) to AuthAuthmeOptions. When true, a missing prompt rethrows the original timeout error instead of falling back to login; everything else in the flow is unchanged.

No automated test — the repo has no unit-test runner in any npm package (only e2e against a real server), and adding one for a single boolean branch felt like more than the change warranted. Verified with tsc --noEmit and both stands:

• plugwrightTestLocal: 50/50 pass
• plugwrightTestStand: 44/44 pass, 6 skip, 0 fail

[Drownek]

Hey @monikon22, thanks for the PR, and for catching the issue with servers that do strict prompt checks

I've been digging through the whole session reconnection flow (including the #57 changes), and I'm not a fan of using a timeout to guess that a session got resumed. It bolts a forced 15s delay onto every session test, and worse, it's a race condition: if CI or the server just lags for a second, we assume a session happened, fire /login blindly, and fail somewhere downstream in a way that's a pain to debug.

Good news is AuthMeReloaded already tells us when a session resumes, it sends a message (the valid_session string, "Logged-in due to Session Reconnection" by default). So why not just listen for that?

Here's what I'm thinking: add a sessionResumedPattern option (default something like 'Session Reconnection'), then have the poll watch for registerPrompt, loginPrompt, or sessionResumedPattern, whichever comes first. Match sessionResumedPattern and we resolve auth as successful immediately, no delay. Hit timeoutMs without seeing any of the three, we throw a strict error, no exceptions.

That gets rid of the 15-second wait, stops us guessing and sending commands blind, and actually lets us drop failOnMissingPrompt too, since a missing prompt now just fails fast on its own.

Up for taking a pass at reworking the PR this way? Let me know what you think

[monikon22]

Makes sense — pushed a rework along these lines.

Added sessionResumedPattern (default Session Reconnection, matching AuthMe's valid_session message), racing it against the two prompts. A match resolves auth immediately with no command sent; anything else within timeoutMs now throws. Dropped failOnMissingPrompt — nothing left to opt out of.

One thing worth flagging: example_plugin's local/stand config had sessions.enabled: false, so the resumed path was never actually exercised there. Flipped it to true and added a rejoin test asserting the resume message arrives with no login/register command sent. Both plugwrightTestLocal (51/51) and plugwrightTestStand (45/45, 6 skip) pass.