Devlog #3

Today, I have finished Phase 2; and everything is working! On top of finishing Phase 2, I have started the multi-user support which I have decided to add.

The Ship Tabacle

Before starting work on Phase 3, I ended up finding out from shipping guidelines that the project, quote “Bots (Discord, Slack, etc…): It has to be hosted! … You can’t leave your bot unhosted with only source code.”

Also implying that it has to be… “Multi-User”

As a result of this, I have decided to add multi-user support, by giving one wwebjs Client to each user, managed by the new client manager: clientPool.js that allow’s everyone to have their own “instance,” group selection, and notifications.
The upside to this way of solving the problem is that most of the components, for example: Classifier, Alerts System, DB Schema, all of that can stay the same, only requiring a few changes to make it compatible for the new Multi User System.

With all of these changes; the new system to register and use the bot is this:

1. User DMs the bot/start
2. Bot asks for their WhatsApp number
3. They reply with it
4. spawnClient(chatId, phone) is called
5. wwebjs emits qr, we call requestPairingCode(phone) instead of sending a QR image
6. The user receives a code like ABCD-1234, enters it in WhatsApp → Linked Devices, anddd…
7. Connected ✅

This simlifies the bot to be User Friendly, to host, and use + allows me to still be able to ship

Problems Encountered

1. “Houston! We have an IPv6 Problem…”

• Problem: bot.launch() was timing out during the getMe handshake with Telegram at random. Worked sometimes, failed other times.
• **Fix:**Added require('dns').setDefaultResultOrder('ipv4first') on index.js, plus a keepAlive HTTPS agent on the Telegraf instance.

2. “Silent Treatment”

• Problem: Bot received /start, asked for phone number, user replied… and you get ghosted.
• Fix: One missing String() cast in /start. Took way too long to find.

3. “The Ghost of Chromium Past”

• Problem: Previous test run left a Chromium process hanging. Next launch: “The browser is already running for auth_data/session-7145622406.”
• Fix: pkill -f chromium + delete the session folder.

4. “t”

• Problem: requestPairingCode threw a single-letter minified error: t. No stack trace, no message. Just… t.
• Fix: Drop the alpha version, and pin the stable 2.3000.1017054665 instead.

5. “The Error in the Error Handler’s House”

• Problem: After bug 4 threw, the catch block tried to DM the user an error message. That also timed out, with the SAME cold IPv6 issue, firing during Chromium’s initial page load which was already hammering the event loop.
• Fix: Wrapped the notification send in its own try/catch. A failed notification shouldn’t throw an unhandled rejection on top of the original error.

What’s Next

• Finish commands: /addgroup, /threshold, /categories, /status, /deals
• restoreAllSessions(): reconnect everyone on process restart
• messageHandler.js: wire live capture per subscriber
• sendDealAlert(): fan-out to all matching subscribers
• Sold detection
• Dashboard post-ship
• First public ship

Devlog 2: XenoDeal | The AI Turns On (And Starts Eating Tokens)

June 22

Since the previous devlog (sorry for missing yesterday), I have gotten the AI System Implemented, and Filtering in order. WhatsApp has caused MORE problems, and luckily I fixed them. (But not the Logout Crash) Besides that, the day (and a half) were easy.

Classifier And Telegram

The Main, MAJOR piece of this devlog and the changes I’ve made since devlog one is src/cron/classifier.js. It’s a background process that does four main things:

1. Grabs Unprocessed Messages from the DB in Batches
2. Runs a separate pre-filter file, that removes Obvious Noise and Junk from the Batch
3. Sends Candidates to AI Provider for full classification
4. Writes the result to the new deals table and marks the message as processed

Roughly ~150 Messages are still not processed, from my testing batch, gathered from Phase 1, and it is still expanding. This is not just the most important part of the project, it’s the… orchestrator if you will.

The batch size is dynamic, and scales every tick based on backlog and load. This is mainly important during boot after downtime as WWJS just replays missed messages as Live Events, causing a MENTAL wave of messages, and this allows the backlog to finish faster.

async function getBatchSize() {
    const r = await pool.query(
        'SELECT COUNT(*) FROM messages WHERE processed = false'
    );
    const pending = parseInt(r.rows[0].count);
    if (pending > 100) return MAX_BATCH;  // 100
    if (pending > 20)  return 50;
    return MIN_BATCH;  // 20
}

The one architectural decision I have made is to DECOUPLE the poller and message create handlers. They can run without the other, and they work at their own pace, so live messages don’t get blocked from inserting, thus less profit.

For Telegram, I just added a threshold for me to get notified about a listing. If it’s score is above 65, it will send me all the details of the listing, the group name, and the original message. An example is attached as an image.

Bugs

1.) “Temperature Card”

• Problem: Same listing was scoring differently
• Fix: Set Temperature to 0.2

2.) “Sorry, I didn’t understand, please try rephrasing that”

• Problem: The AI System thought that it was looking for deals for the End Buyer + Hallucinating Good Condition without Evidence
• Fix: Rewrite Prompt to be more detailed

3.) “Lid, a Big Lid with no Phone # in it”

• Problem: Whatsapp returns a lid ID instead of a number
• Fix: Used an approach using client.pupPage and window.require

4.) “Have you seen Chromium anywhere?”

• Problem: WhatsApp updated and the injection of WWJS made Chromium “Context Crash”
• Fix: Pin a specific version of WhatsApp

What’s Next

The Dashboard has been pushed back until after the first ship, and as phase 2 has been complete, now phase three is the following:

• Train and Implement ML for filtering and deals
• Add Multi-User Support
• Add Setup Flow to Telegram
• Add /cmds to Telegram
• Polish for First Ship

Devlog: XenoDeal | The Listener Wakes Up

June 20

Today was a bit hard (it’s the first day on this project, and I’m catching strays breh). I started with:

1. Planning out the infra
2. Making the project base

The stack for this one is: PostgreSQL, Node.js, Telegraf, and wwebjs.

I ended up building out the basis for the Telegram, PostgreSQL, and WhatsApp wrappers. Telegram and Postgres were easy, being a few lines each, for now. WhatsApp, being the main part of the app, wanted to give me problems. Four total.

Issue 1: Puppeteer ghosting me. Setting up the project, making sure init and env loading worked across all files, Node kept complaining about

“Puppeteer Missing.” I’d just installed it, so I assumed it was fine. Turns out pnpm takes security seriously and silently blocks Puppeteer’s install script by default. To make it worse, I fat-fingered Enter instead of Space on the approve-builds screen, so even the prompt to fix it slipped past me. Couldn’t figure out how to re-trigger the script, so I just pointed it at my system Chromium instead:

const client = new Client({
    puppeteer: {
        executablePath: '/usr/bin/chromium',
        headless: true,
        args: ['--no-sandbox', '--disable-setuid-sandbox']
    },
    authStrategy: new LocalAuth({
        dataPath: 'auth_data'
    })
});

Issue 2: The Logout Crash. I wanted to check that client.on('disconnected') actually fires correctly, so I tested it the easy way: logged out the linked WhatsApp session from my phone. Instead of a clean disconnect, client.on('ready') fired three times, then it crashed:

Failed to add page binding with name onQRChangedEvent: window['onQRChangedEvent'] already exists!

Best guess: wwebjs trying to inject its page bindings into a page that already had them. Possibly a [email protected] version mismatch against what [email protected] actually expects internally, but I’m not fully sure that’s the real cause yet. Problem for another day.

Issue 3: The Silent Hang. Whilst testing the LocalAuth implementation, I Ctrl+C’d the process without realizing Chromium leaves behind a SingletonLock file. Next launch just hung indefinitely; no warning, no error, nothing. Found that out the hard way. I ended up clearing the stale lock and added this so it can’t happen again:

process.on('SIGINT', async () => {
    await client.destroy();
    process.exit(0);
});

tl;dr: It lets Chromium clean up after itself on every manual stop, instead of leaving a corpse behind for next time.

Issue 4: the Date/Time Problem. Setting up message logging, I converted msg.timestamp (Unix seconds) to milliseconds for Postgres with msg.timestamp * 1000. It wasn’t enough. Every insert failed with:

date/time field value out of range: "1782000093000"

Turns out pg doesn’t know what to do with a raw JS number where it expects a date, and just stringifies it and Postgres rejects the result outright. Had to wrap it in an actual Date object:

new Date(msg.timestamp * 1000)

(Need to double check: I remember it still not behaving right away even after this fix, possibly just the client needing a moment to fully reconnect after restart rather than the date fix itself being incomplete. Worth confirming next time it comes up.)

What’s Next

So… reads design docs, according to this, I’ll be establishing Core Intelligence next. Second most exciting part of the whole build. Covers:

• Claude integration (analyze each listing, provide a ranking)
• Sold tracking
• The dashboard

(PS: It did end up working)