bug: 🐛 token refresh is not triggered causing need to re-login every ~7 days

[clins1994]

note: on june 7th i've torn down the bridge and ran it on a clean slate. i will check back on june 14th and provide a more detailed picture then

Bug Report: token refresh is not triggered causing need to re-login every ~7 days

Describe the bug

Some bridge paths do not recover when LINE returns an expired-access-token error. Users can end up needing to manually relogin after the access token
expires, commonly reported as every 7 days / 168 hours.

I recently hit this on my own bridge. The bridge process was still running and Matrix websocket reconnects were working, but an outbound Matrix -> LINE
send failed because LINE returned:

code=10051
TalkException code=119
reason="Access token refresh required"

The bridge already has refresh-token plumbing, but it appears to be applied inconsistently. In particular, the outbound send path can return the SendMessage auth error directly instead of refreshing the token and retrying once.

To Reproduce

1. Login to LINE through the bridge.
2. Keep the bridge running until the LINE access token expires, or otherwise trigger a LINE API call with an expired access token.
3. Send a message from Matrix to LINE.
4. Observe that the send fails with Access token refresh required instead of refreshing and retrying automatically.

Expected behavior

The bridge should either:

1. Refresh the LINE access token proactively before expiry using token metadata such as durationUntilRefreshInSec, or
2. Refresh and retry once when any LINE API call returns code=119 / Access token refresh required.

The user should not need to manually relogin when a valid refresh token is available.

Screenshots or logs

Sanitized log excerpt from my bridge:

{"level":"error","action":"handle matrix event","event_type":"m.room.message","error":"API error 400: {\"code\":10051,\"message\":\"RESPONSE_ERROR\",
\"data\":{\"name\":\"TalkException\",\"message\":\"TalkException\",\"code\":119,\"reason\":\"Access token refresh required\",
\"parameterMap\":null}}","time":"2026-05-28T04:24:27.218385332Z","message":"Failed to handle Matrix message"}
{"level":"debug","action":"handle matrix event","status_code":200,"req_body":
{"status":"FAIL_RETRIABLE","reason":"m.event_not_handled","internal_error":"API error 400: {\"code\":10051,\"message\":\"RESPONSE_ERROR\",\"data\":
{\"name\":\"TalkException\",\"message\":\"TalkException\",\"code\":119,\"reason\":\"Access token refresh required\",
\"parameterMap\":null}}"},"time":"2026-05-28T04:24:28.133625047Z","message":"Request completed"}

Additional context

Relevant code:

• RefreshAccessToken() calls LINE’s /api/auth/tokenRefresh endpoint:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/line/client.go#L479
• refreshAndSave() stores refreshed tokens:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/connector/client.go#L143
• recoverToken() refreshes first, then falls back to re-login:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/connector/client.go#L192
• isRefreshRequired() detects code=119 / Access token refresh required:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/connector/client.go#L178
• The outbound Matrix -> LINE send path calls SendMessage:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/connector/send_message.go#L630
• That path later returns err directly:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/connector/send_message.go#L729
• Token metadata includes durationUntilRefreshInSec, but there does not appear to be a proactive refresh scheduler using it:
  https://github.com/beeper/matrix-line-messenger/blob/main/pkg/line/structs.go#L135

Related discussion:
#162

[clins1994]

ℹ️ restarting the bridge did not require me to login manually

  Logs confirm what happened: the rebuild/startup recovered via refresh token, not QR login.

  Relevant startup sequence:

  2026-05-28T04:56:15.662Z Starting user login
  2026-05-28T04:56:15.768Z Access token expired, attempting refresh...
  2026-05-28T04:56:15.820Z Tokens refreshed and saved
  2026-05-28T04:56:15.820Z Token refreshed successfully
  2026-05-28T04:56:15.821Z LINE client connected; notifying bridge
  2026-05-28T04:56:15.996Z Starting LINE SSE loop...
  2026-05-28T04:56:16.073Z Seeded local revision from getLastOpRevision

  Container metadata:

  started=2026-05-28T04:56:13.573327291Z status=running restart_count=0 exit=0

  So the stored refresh token was valid. The merge/rebuild caused Connect() to run, which calls ensureValidToken(). That path does handle expired tokens
  correctly: it detected the expired access token, called refreshAndSave(), saved the new tokens, and connected.

  This sharpens the bug report: refresh tokens do work on startup, but not consistently at runtime. Your earlier outbound send failed because SendMessage
  hit code=119 while the bridge was already running and that path returned the error instead of calling recoverToken() and retrying.

cc @vkdltjs

[clins1994]

need to centralize auth handling so every LINE API call behaves consistently, but keep the actual refresh trigger conservative unless we have evidence the line chrome extension refreshes proactively

[clins1994]

checked via the /line-capture skill. a proactive approach exists

diagrams

Current Bridge Behavior	Chrome Extension Behavior

token refresh implementation

// main.js
window.setTimeout(() => this.renewToken(), refreshAtMs - currentServerTimeMs)

this.renewToken = ZR(async () => {
  if (!this.tokenV3IssueResult?.refreshToken) {
    throw new Hp(Id.REFRESH_TOKEN_NOT_EXISTS);
  }

  const {
    initialDelayInMillis,
    maxDelayInMillis,
    multiplier,
    jitterRate
  } = this.tokenV3IssueResult.refreshApiRetryPolicy;

  let i = Number(initialDelayInMillis);

  for (; i < Number(maxDelayInMillis);) {
    try {
      const e = await OD(
        { retryCount: 0 },
        this.tokenV3IssueResult.refreshToken
      );

      this.setTokenV3IssueResult({
        ...this.tokenV3IssueResult,
        ...e
      });

      await VA().saveTokenV3IssueResult(this.tokenV3IssueResult);

      const t = cT();
      return void (
        t.sdk.readyState === HA.ReadyState.OPENED &&
        t.connect()
      );
    } catch (o) {
      if (uM(o) !== qU.AUTH_RETRY_REQUIRED) throw o;

      const e = i * HR(1 - jitterRate, 1 + jitterRate);
      i *= multiplier;
      await _R(e);
    }
  }

  throw new Hp(Id.TOKEN_REFRESH_FAILED);
});

init/reopen

async init() {
  const e = VA().getTokenV3IssueResult();

  if (!e.accessToken) {
    throw new Hp(Id.ACCESS_TOKEN_NOT_EXISTS);
  }

  await getServerTimeEquivalent();
  this.setTokenV3IssueResult(e);
}

this proves

1. Refresh is proactive: setTimeout is created from tokenIssueTimeEpochSec + durationUntilRefreshInSec.
2. Refresh response replaces/merges tokenV3IssueResult.
3. New token data is persisted.
4. setTokenV3IssueResult is called again, rescheduling the next refresh.
5. If SSE is already open, it reconnects after refresh.
6. Refresh retry uses server-provided retry policy with exponential backoff and jitter.

[highesttt]

Hi!
I've not been able to reproduce this; I haven't relogged on my LINE account manually since mid april and I always use the latest commit available 🤔
I might need more details to look into this, like:

• which commit are you currently on
• does your account have letter sealing on or off
• does it work if you just restart the bridge
  • if so, what was the last activity that you did where the token did not refresh, just send messages? was that in a group or a dm? LSON/LSOFF?
• has your bridge been constantly running or were there restarts

Thanks!

[clins1994]

@highesttt hey hey. i dozed off on this and would like to reset ... so from today (June 7th) i've torn down the bridge and ran it with a clean slate on 2914bdb009670a28f8e05100787abb003a52da92 commit. i will keep an eye out according to the points you requested

for what its worth

• which commit are you currently on 2914bdb009670a28f8e05100787abb003a52da92
• does your account have letter sealing on or off on
• does it work if you just restart the bridge previously, restarting the bridge did log me back in
• if so, what was the last activity that you did where the token did not refresh, just send messages? was that in a group or a dm? LSON/LSOFF? can't remember
• has your bridge been constantly running or were there restarts at least one restart and for sure pushing new builds

[clins1994]

@highesttt hit it this weekend. here's criterias and automated report on top of the logs

Criterias

• which commit are you currently on 2914bdb009670a28f8e05100787abb003a52da92
• does your account have letter sealing on or off on
• does it work if you just restart the bridge restarting fixed the issue
• if so, what was the last activity that you did where the token did not refresh, just send messages? was that in a group or a dm? LSON/LSOFF? just send normal messages
• has your bridge been constantly running or were there restarts at least one restart and for sure pushing new builds constantly running since June 7th
• i'm running it on a linux server

AI Generated Report (GPT 5.5)

The bridge hit LINE token expiry on 2026-06-14 06:27:43 UTC. Two outbound Matrix-to-LINE sends failed with:

TalkException code=119, reason Access token refresh required

The bridge then marked both sends as FAIL_RETRIABLE, but I found no follow-up log showing refresh or re-login:

• no Token recovered via refresh
• no Tokens refreshed and saved
• no Token refreshed successfully
• no Login successful

So it stayed “connected” to Beeper/Matrix while LINE outbound sends were effectively dead behind an expired LINE access token. The repeated SSE Disconnected ... connection reset by peer entries are noisy but not the root cause. There was also a short Docker DNS hiccup on June 14 22:41 UTC, but it recovered and is unrelated.

Code-side, HandleMatrixMessage sends with the current access token and returns LINE error 119 directly. Token recovery exists elsewhere, especially on startup and some sync/media paths, but normal outbound sends do not refresh-and-retry on this error. That matches your prior observation that a restart logs you back in.

The container has been running since the June 7 reset window. The visible repo is now at 4c7e069, but the running image was built on June 7, before the June 9 commits, so it was likely built from 2914bdb; the image just does not have a commit label to prove it.

Permanent fix is to add one auth-recovery retry around outbound SendMessage when LINE returns code 119 / Access token refresh required.

[clins1994]

@highesttt also ... it is strange that it doesn't even show me i'm in a bad auth state nor asks me to re-auth from the beeper mobile client. messages show as "sent" on beeper mobile client but my peer never receives it