Open JGreenlee opened 6 months ago
The assertion errors are validation or quality control checks on the pipeline. They are turned on by default in dev versions so we can see what is going wrong. In this case, it is almost certainly
2024-05-06 01:43:14,507:ERROR:140704544475072:Section counts = [47272, 144, 120], expecting 1
But if you would like to ignore that for now since it is not a section you worked on, you can turn off the various assertion errors in conf/analysis/debug.conf.json
In that case, it should not affect production right? This opcode does not have any trips on production either
It doesn't have any trips on production because I upgraded DFC fermata to the version with the BLE matching, and reset the pipeline for all users so that the trips and sections would be re-created and we could generate a snapshot with the correct data format for public dashboard testing. https://github.com/e-mission/em-public-dashboard/pull/124#issuecomment-2095191220
The trips should be showing up soon, or any errors will be in the intake pipeline logs.
Ah I see, I thought it would have finished processing by now
Circling back to this and confirming that I was able to get my trips to process locally by turning off the assertion errors.
I'd still like to know why my sections were considered "invalid" (I've also seen logs saying "This is messed up segment. Investigate further while processing section, skipping...") But that might be a hairy topic that we don't have time to dive into now
e-mission-server
master
dfc-fermata
Inspect the cleaned objects for my opcode:
Output:
./e-mission-py.bash bin/reset_pipeline.py -e nrelop_dfc-fermata_test_████
Run pipeline for user
./e-mission-py.bash bin/debug/intake_single_user.py -e nrelop_dfc-fermata_test_████
"Cleaning and resampling failed"