Closed adamscarberry closed 3 years ago
@adamscarberry - looks like that call was just to make sure the latest timeseries were all active. I was able to filter the list just by checking the instrument_id matched the current instrument. Probably not the best fix but going back through and updating the timeseries bundle would be time consuming and fairly invasive.
Let me know if you still see issues with that list or anything else. Thanks!
Thanks @KevinJJackson that fixes the immediate need. I'll let @brettpalmberg determine if/when he wants further changes made to the timeseries bundle.
Thank you @KevinJJackson @adamscarberry - this sounds like a good fix. If this addresses the immediate bug (data for a different instrument shown when it should not be), I think we can close this issue. There are some more invasive optimizations needed in the timeseries
/ timeseries_measurements
bundles too - we can tackle those in another issue / PR.
This usually happens when a project has multiple instruments and at least one instrument has one or more timeseries. For instruments in that project that do not have timeseries, bogus timeseries will appear.
Example in local testing seed data:
Project: Northwestern Division Missouri River Streamgages
Instrument: ADAK-Ada-Salt (f41c9f66-47c2-4718-9af9-9bdc2f32b632)
In the seed data this instrument has no timeseries, but a ton of timeseries will appear for the instrument (see below):
It appears an API call to /instrumentation/timeseries ( which calls handlers.ListTimeseries(db) ) happens for the instrument page load when perhaps it should be: /projects/:project_id/instruments/:instrument_id/timeseries which would call handlers.ListInstrumentTimeseries(db)