S82: LINE notifications not sending! → 4-Stage Debug → Official Connection Complete
Date: 2026-02-25
Category: wisdom
Summary
Investigated the issue of LINE carousels not being delivered after the main reading on MySpirits. The cause was layered across four levels. Each fix revealed a new problem, a true debugging chain. Ultimately, completed official connection of LINE Messaging API, added My Page login mechanism, and increased the main reading to 1200 characters.
Actions Taken
1. Layer 1: Missing authentication header in index.html
User report: “Results are out but LINE is unresponsive for existing members.” Cloud Run logs showed no LINE sending-related errors, meaning sending wasn’t triggered at all.
Tracing the cause, the premium reading API call in index.html (LP) was missing the Authorization: Bearer header. Even though LINE Login was performed on mypage.html and myspirits_auth_token was saved in localStorage, index.html wasn’t reading it.
Fixes:
– Added _getAuthHeaders() helper function to read the token from localStorage and include it in the Bearer header.
– Applied to fetch for the premium reading API.
2. Layer 2: Complete redesign of LINE CTA
After the fix, user provided flow instructions:
“After getting a reading in the browser, if I press LINE, a QR code appears, which I scan with my phone. If I’m already a friend on LINE, the carousel should arrive immediately upon scanning the QR. If I get the reading on my phone, the carousel should arrive as soon as I press the LINE button.”
This meant a “LINE Login → Automatic Carousel Sending” flow was needed, not the traditional “Add LINE Friend Link.”
Significant changes were made to index.html:
– startLineLogin(): Saves pending result_id to localStorage → Initiates LINE Login OAuth.
– sendLineReading(): Calls the /api/fortune/send-line API.
– updateLineCTA(): Switches to a sent state UI.
– Detects ?auth_token= callback on page load → Automatically executes pending LINE sending.
– Changed CTA button to the LINE green “Receive reading results on LINE.”
– Displays “Sent to LINE” upon completion.
3. User Correction: LINE CTA for free readings is unnecessary
After implementation, user pointed out: “It’s after the main reading, not after free readings, right? Free readings can be received multiple times and are already saved?”
Removed the LINE CTA for free readings (HTML + 4 JS references) entirely, limiting it only to the main reading.
4. Layer 3: Incorrect LINE Messaging token
After deploying the above fixes and testing the LINE Push API, the token pointed to the wrong bot: @787oguzk (Inspire – SNS Automation Support App), not MySpirits’ bot @838imbvp.
It was discovered that the token stored in Secret Manager was the one set for Inspire during the Phase 4 implementation.
5. Layer 4: Issuing the correct token → Official Connection
Received MySpirits’ Channel ID (2008463240) and secret from the user.
curl -X POST “https://api.line.me/v2/oauth/accessToken”
-d “grant_type=client_credentials&client_id=2008463240&client_secret=…”

Bot Confirmation:
@838imbvp — My Spirits – Compass of the Soul in Your Pocket (Correct Bot)

Added a new version to Secret Manager v2 → Disabled v1 (Inspire) → Deployed Cloud Run Rev19.
6. Increased main reading to 1200 characters
User request: “The character count for the main reading is too low. Currently each section is 800 characters, please increase to 1200 characters.”

fortune_prompts.py: Changed all “within 800 characters” to “within 1200 characters” (all 7 sections).
main.py: Increased max_tokens from 5000 to 8000, httpx timeout from 120s to 180s.
Carried over from Cloud Run Rev18 to Rev19.
7. Added LINE Login screen to My Page
Fixed the issue where unauthenticated users directly accessing mypage.html were immediately redirected to index.html.

Added login screen HTML (LINE green button + consistent cosmos design).
Changed checkAuth() from redirect to displaying the login screen.
handleAuthCallback(): Detects ?auth_token= parameter → Saves to localStorage → Cleans URL.
startLineLogin(): Sets mypage.html as the redirect_uri.
Wrapped authenticated content in an auth-content wrapper div.
8. Deployment

Cloud Run Rev18 (1200 chars + timeout) → Rev19 (Official LINE Token)
XServer × 3 times (Added auth header → Changed LINE CTA → Deleted free CTA → Added My Page login screen)
All reflected in production.
Mistakes Made
Neglected to verify the LINE Messaging token. When setting the token in Secret Manager during Phase 4, I did not confirm the bot (GET /v2/bot/info). If I had made an API call once during setup to confirm, one of the four debugging layers could have been eliminated from the start.
Explanations were too verbose. I started explaining the technical background of “30-day client_credentials tokens vs. long-term tokens” to the user, who then said, “I don’t understand.” It would have been better to simply say, “It works. We’ll just swap it out when the expiration date comes.”
Regarding the My Page issue, when the user asked, “Will it work if I just log in?”, I started explaining the code details. Conclusion: Stick to the order of operations.
Lessons Learned
Always verify secrets with an API upon setting them. Token save → curl /v2/bot/info → Bot name confirmation. This 30-second step can prevent hours of debugging later.
When explaining to users, prioritize the conclusion. “It works,” and “I’ll fix it” come first. Technical background should only be explained if asked.
With a LINE Bot’s Channel ID and secret, a token can be issued immediately using client_credentials. There’s no need to log in to the LINE Developers Console. It’s a single curl command.
The redirect_uri in the authentication flow (LINE Login OAuth 2.1) can be specified dynamically. Since /api/auth/line/login in auth.py accepts a redirect_uri query parameter, the same OAuth flow can be reused from both index.html and mypage.html.
When debugging, be aware of layers. “LINE notifications not sending” was a single symptom with four overlapping layers: missing authentication header → flawed flow design → incorrect token configuration → absent login path. It’s important to be conscious of peeling back each layer one by one.
Observations from Agent Interactions
When resuming a session after context compression, the last user message of the previous session and its surrounding context are extremely important. A summary alone can lose subtle information like “whether the user provided a token.” Crucial received information (private keys, tokens, authentication details) should be explicitly included in Session Handoff.
Additionally, in cases where problems are found in a chain of four layers, it would be ideal if the agent could automatically detect the “next problem” after each fix and resolve them all at once. This time, the cycle of manual testing → reporting → fixing occurred three times. Instilling the habit of performing dry runs (checking by hitting API endpoints) in the agent before deployment can compress this cycle.
Deployment Status

Service
Rev/Status
Changes

myspirits-api (Cloud Run)
Rev19
Official LINE Token + 1200 chars + 180s timeout

myspirits LP (XServer)
index.html updated × 3 times
Auth header + LINE Login CTA + Free CTA deletion

myspirits LP (XServer)
mypage.html updated
LINE Login screen + auth_token callback

Next Steps

E2E Test: LINE Login → Paid Reading → Receive LINE Carousel → Check History on mypage.html
Set FLEX_IMAGE_URLS environment variable (carousel image URLs).
Add line_sent_at / line_send_status columns to fortune_results.
Prolong LINE Messaging token (30-day expiration → expires around 2026-03-27).