Auto-start both processes at logon and self-update from master
Instances were started by hand and updated by hand, so they drifted behind master silently. Now: PM2 supervises the dashboard and the clicker, a logon task brings them up, and a 5-minute task pulls, rebuilds and restarts when master moves. Restarting on every push is only safe because the scheduler now survives it. It was pure in-memory state (_global.__autoTrader), so any restart silently stopped automated trading with the dashboard simply showing it as off. It now mirrors running/action/symbol/stopAfterAll to the settings table, and resumeSchedulerIfPersisted() picks it back up from the getClients() bootstrap. No sync-wait was needed there: tick() already skips while a client reports !syncComplete and while any account holds a position. A failed build is never deployed — the build runs before anything restarts, so a broken push leaves the previous build serving. start-all and update-check both warm the app with a request afterwards. That is load-bearing: getClients() is lazily bootstrapped, so until something makes an HTTP request the Tradovate clients, the reporter and the resumed schedule never start. That was already true of manual restarts. Logic lives in Node so a macOS or Linux port only needs an equivalent of install-autostart.ps1. Python deps are hash-guarded, so the common path is one hash and one import with no network, and failure is non-fatal since only the clicker needs them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
7e7bd985c2
commit
4288d8c298
@@ -152,44 +152,41 @@ dialog stealing focus fails the step. That makes an RDP session a poor host:
|
||||
disconnecting can suspend the desktop and break clicks in ways that are hard to
|
||||
diagnose.
|
||||
|
||||
## Keeping it running (PM2)
|
||||
## Keeping it running
|
||||
|
||||
Install PM2 globally:
|
||||
`setup-windows.bat` offers to set this up for you at step 6. To enable it later,
|
||||
or after declining:
|
||||
|
||||
```powershell
|
||||
npm install -g pm2
|
||||
npm install -g pm2-windows-startup
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File scripts\install-autostart.ps1
|
||||
```
|
||||
|
||||
Start the app and save the process list:
|
||||
That registers PM2 for both processes and two scheduled tasks — one to start
|
||||
everything at logon, one to check `master` for updates every 5 minutes. It needs
|
||||
no elevation and is safe to re-run; it replaces the tasks rather than stacking
|
||||
them up.
|
||||
|
||||
```powershell
|
||||
cd C:\path\to\autofirmer
|
||||
pm2 start "npm start" --name autofirmer
|
||||
pm2 save
|
||||
pm2-startup install
|
||||
pm2 list # what is running
|
||||
pm2 logs autofirmer # dashboard output
|
||||
pm2 logs clicker # runner output
|
||||
```
|
||||
|
||||
To restart after pulling updates:
|
||||
**Why scheduled tasks and not a Windows service.** The clicker sends real mouse
|
||||
and keyboard input and has to own a desktop. A service runs in session 0, which
|
||||
has none, so the clicks would go nowhere. Both tasks therefore run as you with
|
||||
"run only when user is logged on" — which also means an unattended reboot leaves
|
||||
the instance down until somebody logs in.
|
||||
|
||||
To start everything by hand without waiting for a logon:
|
||||
|
||||
```powershell
|
||||
cd C:\path\to\autofirmer
|
||||
git pull
|
||||
npm install
|
||||
npm run build
|
||||
pm2 restart autofirmer
|
||||
node scripts\start-all.mjs
|
||||
```
|
||||
|
||||
If the update touched the AutoBuyer, two things do **not** reload themselves:
|
||||
`start-autofirmer.bat` still runs the dashboard in a visible window without PM2,
|
||||
which is the easier thing to watch when a build is misbehaving.
|
||||
|
||||
- **The extension** — click reload on its card in `chrome://extensions`.
|
||||
- **The runner** — stop it with Ctrl-C and start it again.
|
||||
|
||||
The dashboard reports the version it sees from each, and warns when either is
|
||||
behind. Most AutoBuyer bugs that look mysterious are one of these two still
|
||||
running the previous code.
|
||||
|
||||
---
|
||||
|
||||
## Firewall
|
||||
|
||||
@@ -209,19 +206,33 @@ New-NetFirewallRule -DisplayName "AutoFirmer" -Direction Inbound -Protocol TCP -
|
||||
|
||||
## Updating
|
||||
|
||||
Once auto-start is installed, nothing here is manual. Every 5 minutes the update
|
||||
task fetches `master`, and when it has moved it pulls, reinstalls dependencies if
|
||||
`package-lock.json` or `clicker/requirements.txt` changed, rebuilds, restarts
|
||||
AutoFirmer, and restarts the clicker if anything under `clicker/` changed.
|
||||
|
||||
**A failed build is never deployed.** The build runs before anything restarts, so
|
||||
a broken push leaves the previous build serving and logs the failure instead.
|
||||
|
||||
Everything it does is appended to `scripts/update.log`. To see what it would do
|
||||
without touching anything:
|
||||
|
||||
```powershell
|
||||
cd C:\path\to\autofirmer
|
||||
git pull
|
||||
npm install # only needed if dependencies changed
|
||||
npm run build
|
||||
pm2 restart autofirmer
|
||||
node scripts\update-check.mjs --dry-run
|
||||
```
|
||||
|
||||
If the update touched the AutoBuyer, two things do **not** reload themselves:
|
||||
To apply an update immediately rather than waiting for the next check:
|
||||
|
||||
```powershell
|
||||
node scripts\update-check.mjs
|
||||
```
|
||||
|
||||
### The two things that still do not reload themselves
|
||||
|
||||
- **The extension** — click reload on its card in `chrome://extensions`.
|
||||
- **The runner** — stop it with Ctrl-C and start it again.
|
||||
- **The scheduler is fine now.** It persists to the settings table and resumes
|
||||
after a restart, so an update no longer silently stops automated trading.
|
||||
|
||||
The dashboard reports the version it sees from each, and warns when either is
|
||||
behind. Most AutoBuyer bugs that look mysterious are one of these two still
|
||||
running the previous code.
|
||||
The dashboard reports the version it sees from the extension and the runner, and
|
||||
warns when either is behind. Most AutoBuyer bugs that look mysterious are the
|
||||
extension still running the previous code.
|
||||
|
||||
Reference in New Issue
Block a user