I have to relogin every 7 days.

[vkdltjs]

Is this a normal behavior?
I'm using v1.1.0, and matrix client.
Exactly after 168 hours (24*7), line message is not bridged to matrix and I have to relogin.

[clins1994]

TL;DR token refresh flow isn't supported yet (immature setup / partial). We should make an issue for it. More info:

EDIT: issue created: #163

I don’t think this is intended behavior. I recently hit what looks like the same class of failure on my own bridge, and the logs point to LINE access-token expiry / refresh handling.

In my case the bridge process was still running and the Matrix appservice websocket was reconnecting normally, but an outbound Matrix -> LINE send failed with:

2026-05-28T04:24:27Z
Failed to handle Matrix message
API error 400:
  code=10051
  TalkException code=119
  reason="Access token refresh required"

Sanitized log excerpt

{"level":"debug","req_id":1,"ws_command":"transaction","transaction_id":"<redacted-matrix-transaction-id>","content":{"pdu":1},"time":"2026-05-28T04:24:27.109324592Z","message":"Starting handling of transaction"}
{"level":"debug","req_id":1,"ws_command":"transaction","transaction_id":"<redacted-matrix-transaction-id>","time":"2026-05-28T04:24:27.109652445Z","message":"Finished dispatching events from transaction"}
{"level":"debug","event_id":"<redacted-matrix-event-id>","session_id":"<redacted-megolm-session-id>","time":"2026-05-28T04:24:27.109859616Z","message":"Decrypting received event"}
{"level":"debug","event_id":"<redacted-matrix-event-id>","session_id":"<redacted-megolm-session-id>","action":"decrypt megolm event","sender":"<redacted-matrix-user>","sender_key":"<redacted-sender-key>","message_index":6,"decrypted_event_type":"m.room.message (message)","time":"2026-05-28T04:24:27.114758939Z","message":"Event decrypted successfully"}
{"level":"error","portal_id":"<redacted-portal-id>","portal_receiver":"<redacted-line-mid>","portal_pointer":"<redacted-portal-pointer>","portal_mxid":"<redacted-matrix-room-id>","event_loop_index":140,"action":"handle matrix event","event_id":"<redacted-matrix-event-id>","event_type":"m.room.message","sender":"<redacted-matrix-user>","login_id":"<redacted-line-mid>","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","portal_id":"<redacted-portal-id>","portal_receiver":"<redacted-line-mid>","portal_pointer":"<redacted-portal-pointer>","portal_mxid":"<redacted-matrix-room-id>","event_loop_index":140,"action":"handle matrix event","event_id":"<redacted-matrix-event-id>","event_type":"m.room.message","sender":"<redacted-matrix-user>","req_id":293,"method":"PUT","url":"https://matrix.beeper.com/_hungryserv/<redacted-user>/_matrix/client/v3/rooms/<redacted-room>/send/com.beeper.message_send_status/<redacted-txn>?user_id=<redacted-bot-user>","duration":913.860393,"status_code":200,"response_length":73,"response_mime":"application/json","beeper_request_id":"<redacted-request-id>","req_body":{"m.relates_to":{"rel_type":"m.reference","event_id":"<redacted-matrix-event-id>"},"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}}","relates_to_txn_id":"<redacted-txn-id>"},"time":"2026-05-28T04:24:28.133625047Z","message":"Request completed"}

So this was not a Matrix client disconnect or bridge crash. LINE explicitly returned Access token refresh required.

Looking at the code, the bridge already has some refresh-token plumbing:

• RefreshAccessToken() calls LINE’s /api/auth/tokenRefresh endpoint.
• refreshAndSave() stores the new access/refresh token.
• recoverToken() tries refresh first, then falls back to re-login.
• isRefreshRequired() detects code=119 / Access token refresh required.

But the recovery is not applied consistently everywhere. In particular, the Matrix -> LINE send path calls:

sentMsg, err := client.SendMessage(...)

at HandleMatrixMessage() / send path, and later just returns the error if it is still non-nil:

if err != nil {
    return nil, err
}

See send_message.go. It handles some special retry cases like unsupported file upload and missing group E2EE key, but it does not appear to refresh the LINE token and retry when SendMessage returns code=119.

There is also a durationUntilRefreshInSec field in the token response struct, but I don’t see a proactive refresh scheduler using it. That makes me suspect the bridge is currently relying mostly on reactive refresh after an API call fails, and some call paths don’t recover correctly.

So my current understanding is:

• 7-day expiry itself may be normal LINE token behavior.
• Having to manually relogin every 7 days is probably a bridge bug.
• The bridge should refresh the access token before expiry, or at least refresh-and-retry once when LINE returns code=119.
• The fix should probably centralize LINE API calls behind a token-aware wrapper, so every LINE request path gets consistent refresh/retry behavior.

PR #124 adds QR login and includes some token recovery improvements, but I don’t think it fully solves this specific issue by itself. I was already testing that branch when I saw the Access token refresh required failure, and the failing path was outbound SendMessage, which still needs token refresh/retry handling.