Skip to content

Complete rewrite of database layer#2

Open
TheTechRobo wants to merge 2 commits into
masterfrom
new-queue
Open

Complete rewrite of database layer#2
TheTechRobo wants to merge 2 commits into
masterfrom
new-queue

Conversation

@TheTechRobo

@TheTechRobo TheTechRobo commented Jun 27, 2026

Copy link
Copy Markdown
Owner

First commit was from February, geez...

things still to do (off the top of my head):

  • Actually implement recursion. This should be fairly easy, add an API endpoint to queue pages and do that from the client. Depth should already be handled.
  • Polish dashboard
    • Reimplement a few helpers
  • Add !ig/!unig aliases for reject + skip rules and their corresponding removal
  • Workers should report disk space to the server
  • Display a relation graph on the dashboard (this one can maybe wait)
  • Find all the overengineered stuff :-)
    • Decide whether the job rules system is necessary, or if it should just be a list of accept/reject regexes where reject takes precedence. (Perhaps skip rules should continue to be separated from reject rules in that case, though.) I don't know how useful varying user agent is between different parts of a job (especially considering those different parts could simply be split into multiple jobs - queuing to other jobs will be considered supported behaviour).
      • Actually, I kind of like the idea of having a separate array for each type of rule. That would also make it much easier for users to reason about.
    • Probably remove claim locks. UNTIL_FINISHED is covered by job tags (just make a new one that only has the pipeline(s) you want) and I can't really see a use case for INDEFINITELY. The only thing that tags don't cover for UNTIL_FINISHED is being able to fine-tune exactly how many of each pipeline there will be for a job, if concurrency > 2. Given that it's not much code, I'm open to keeping it in there for awhile in case it is considered useful.

Systems other than brozzler will probably be implemented with a
configuration option, not this enum.

Actionless jobs (i.e. JobType.NONE) are a hack. If they are desired,
they can be emulated with a tag that owned by no pipelines, which
avoids tainting the entire system's design with them. (This could
be useful for, e.g., a simple way of storing results from custom JS
over multiple pages, where otherwise you would need to merge the
CUSTOM_JS result for each page.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant