The simplest possible call queue
Originally posted to my internal blog at VaccinateCA
Today I’ve been working on the queue calling mechanism for the new Django backend.
We want to do a trial run of the system as soon as possible, so I opted to create the simplest possible version of this that could work.
The Django app is going to work a little bit different from our existing Airtable system. The Airtable system defines a number of different filtered views for locations that we want to call, and leaves it to our caller app to load in rows from those views, select a random location from the options and “lock” that location so no-one else is given it to call for at least twenty minutes.
For the new system, we’re going to switch to having an explicit “locations to call” list, which our staff can add locations to and manipulate. This will continue to evolve over time—there’s already discussion of having multiple queues, and assigning different callers to different queues depending on their status and trainining.
For the moment though, the simplest thing is to have a database table with a list of locations that need to be called in it.
I implemented the first version of this in issue 70. I’m using Django’s admin actions mechanism, which allows you to add bulk actions to the admin change list for any model.
The neat thing about admin actions is that you can apply them to multiple rows in the Django admin action interface: by clicking their checkboxes, by shift-clicking a range of checkboxes or with a “select all” option that can apply to the current page or every row that matches the current set of filters.
Combined with a rich set of filters this is a really powerful way of applying bulk actions to items in your database. The admin actions framework then provides a Django ORM queryset to your action code, which can act on it however it wants.
My first version of the code adds a new admin action for each of the “call request reasons” in the database (currently four, but more to come shortly).
Here’s an animated demo showing how the new mechanism works:
Next up: implement the
/api/requestCall API that the caller app uses to fetch the next location that the user should call! #54
The Django app on Google Cloud
Alex Vandiver has done a superb job getting the Django app in a state where it can run on our Google Cloud infrastructure. Most of today’s commit activity was from Alex, and in addition to having continuous deployment running via Google Cloud Build and Cloud Run thanks to Alex we also have improvements like isort, python-dotenv and the (new to me) django-migration-linter.
More recent articles
- Weeknotes: Parquet in Datasette Lite, various talks, more LLM hacking - 4th June 2023
- It's infuriatingly hard to understand how closed models train on their input - 4th June 2023
- ChatGPT should include inline tips - 30th May 2023
- Lawyer cites fake cases invented by ChatGPT, judge is not amused - 27th May 2023
- llm, ttok and strip-tags - CLI tools for working with ChatGPT and other LLMs - 18th May 2023
- Delimiters won't save you from prompt injection - 11th May 2023
- Weeknotes: sqlite-utils 3.31, download-esm, Python in a sandbox - 10th May 2023
- Leaked Google document: "We Have No Moat, And Neither Does OpenAI" - 4th May 2023
- Midjourney 5.1 - 4th May 2023
- Prompt injection explained, with video, slides, and a transcript - 2nd May 2023