Closed OAGr closed 2 months ago
Latest commit: f87b34fa94f45eef23ec1aad7f524a08c489bbe6
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Updated (UTC) |
---|---|---|---|
quri-hub | ✅ Ready (Inspect) | Visit Preview | Apr 12, 2024 2:36am |
My main concern is that buildRecentModelRevision will get stuck on the first model that will fail because of memory or almost-infinite loops.
Yea, I thought about that too. Wasn't sure how likely it would be.
Seems simple enough to try this, then handle errors when they come, or in future PRs. As you know, I like doing things incrementally.
So maybe something like buildStatus field should be stored on the DB level? Probably makes more sense in ModelRevisionBuild, not on ModelRevision. Then we could inject the build flagged as pending immediately, and then update it after the job is completed.
It might even make sense to separate "build results" (squiggle output + errors) from "build runs" (jobs for running a build). Then we won't have to worry about null fields on pending builds.
I imagine this is the most critical if we have multiple workers that can build items that are pending - this way they wouldn't conflict with each other. I'm not sure how much of a priority this is though, it might be a while until we have that.
Run
pnpm run build-last-revision
, to build the last revision. This will create a "build", that will run the squiggle model, and save the Exports for that revision, if it succeeds. If it fails, it will store a simple string error message.