OK I changed it to 60 second timeout. Can you try again?
When you run the query by clicking the web page, it is against the many millions in the archive.
When the query runs during alert ingestion, it is against a few thousands in the latest batch. That needs to execute in 10 seconds or less or else hold up the pipeline.
I’ve set up these filters as streams now as well. Would you recommend using “History” rather than “Run Filter” as my routine to visually inspect recent transients?
Chris – Finally I am ready to answer your question about History versus RunFilter. There were some bugs and some issues and some fixes and pushes, but now we are OK. Lasair relies on the idea that running a SELECT filter on the website or API delivers the same results as when that filter is made active with Kafka/Email. You basically get the same results.
BUT this is not true if your filter includes sorting with ORDER BY. See for example order_of_brightness filter, which includes the clause ORDER BY objects.gmag. If you click “Run Filter”, you get the brightest first, obviously. But the History reflects what went out from the streaming filter, which is always in time order, no matter what you said in the ORDER BY. The streaming is done on batches of 40,000 alerts, one every few minutes, so it orders within the batch only, not on the entire result. – Roy
For your visual inspection, probably the best thing would be to get email output. This is restricted to one message per 24 hours, as a digest. We have had a bit of trouble with emails not getting through, would be great if you could try this setting and tell me if it works.