Community
Chat Logs
Saturday, March 21, 2026
- * phaleth joined #primate
- phalethhi blue, can you hop on the VPS and get into primate website container `sudo machinectl shell 000000-primate-web` and check the logs `journalctl -n 500 -f -u primate-web`? there are a bunch of weird errors that are I guess non-fatal, but still look weird
- * perigrin_ joined #primate
- * onosendi_ joined #primate
- bluephaleth: ya
- blueMar 21 10:10:43 primate-web edge[55]: [ERROR] headers has no key Accept
- blueyou mean this?
- phalethyeah, all of those
- blueI think it's all probably somebots
- blueit looks like AI trying to update its cache, because it's accessing the .md version of pages that no longer exist
- blueMar 21 09:56:05 primate-web edge[55]: [ERROR] no view docs/guides/databases/use-surrealdb.md
- blue.md are the markdown version ofpages, and they're referenced in https://primate.run/llms.txt
- bluethe missing Accept headers are faulty clients, I think
- bluehttps://github.com/primate-run/primate/blob/master/packages/core/src/private/frontend.ts#L175
- phalethcan those client side errors be turned off for production builds? for debugging those might be interesting
- phalethin other words can you set log level of those to DEBUG?
- bluehttps://github.com/primate-run/primate/blob/master/packages/core/src/private/request/RequestBag.ts#L97
- bluespecifically it's this line
- blueand then this
- bluehttps://github.com/primate-run/primate/blob/master/packages/core/src/private/error.ts#L94-L96
- blueso what I could do, in https://github.com/primate-run/primate/blob/master/packages/core/src/private/frontend.ts#L175
- blueis use .try instead of .get
- blue.get is *supposed* to throw if the key is not found, it's a hard condition
- blueand I think the semantics of using .get there are simply wrong, it's ok to not provide an Accept, I think
- bluea bit weird, but ok
- phalethif haproxy let the request through then it's an ok request
- phalethlets*
- bluetry. as said, it's just weird clients that do not specify an "Accept" header at all, and primate assumes there all clients do. the invariant is too strong
- blues/try/true/
- phalethfor Accept header specifically, not setting Accept means expecting the default Content-Type in response, nothing wrong with that
- blueanyway, I'll change the code, but I won't release a new version for it. if that bothers you edit packages/core/lib/private/frontend.js#89
- blueand change .get to .try
- phalethok, thanks, I guess those logs are too few, can wait for new release later
- bluephaleth: https://github.com/primate-run/primate/commit/03b8838be022c8b7bc7c8cc6825fccb26cf65723
- nevetcore/frontend: use try instead of get when checking the request Accep… · primate-run/primate@03b8838
- phalethalso in case of primate website there is actually no need for a release as it's build against master
- phalethit may not build against current master, but that's another thing
- blueyes but I do rather you won't redeploy just yet because the docs are now geared to .37
- bluethis is an unsolved problem for me yet. I thought of changing the redeployment branch to .36, but that's insane. I would have manage two docs versions and port forward any fixes
- phalethno worries, I've made a backup of the primate website container
- blueit's all fine, the changes aren't great so far. it's just the baking .37 blog post, and the modules page
- phalethcurrently I'm testing the new shiny edgejs runtime and watching it leak memory all over the place
- blueI really don't know how to version docs in a way that's not a total pain in the butt
- blue(edgejs was written by a clanker)
- phalethyes, by clanker
- blueso clanker told me, split your docs into docs/master and docs/next or so. but that's so crazy
- bluebecause I'd need to have two duplicated docs tree
- blueand then still make some changes in both
- phalethif needed we can always just git checkout whatever primate can build the primate website and fetch the markdown files for docs separately
- blueand then when I do a new release, I need to cycle it, cp next into master
- bluethe next-to-be idea is, have the website actually do a git peek or whatever it's called in the git branch for the last version
- bluenext-to-best*
- bluethen I don't need to duplicate anything, but I still need to update docs fixes in both master and the last branch.. which is I guess acceptable
- blueand then I'd need to add a dropdown in the website between master and last version
- blueit's really not worth versioning docs between non-majors, I feel
- phalethjust keep single master branch and keep going for now, one day you will have a release and you will fix the build
- blueya