Question: server/files/metadata reflects live state #102
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While using a Moonraker client (moonraker-obico) I noticed a few things around
server/files/metadatathat seem to come from the endpoint being built from live print state rather than from the file. Wanted to ask whether these are intended before assuming they're bugs.Note: I start prints directly from Anycubic Slicer Next, not through the bridge, so the file is not in the bridge's GCode store (/kx/files is empty). Some of the points below may be related to that.
1.
filenameparameter is ignoredAny query returns the running job's metadata, even for a non-existent file:
returns metadata for the currently printing file. Also on this endpoint,
sizeis1for files not in the store andestimated_timeisnull, though both seem available fromburied/report(gcode_size,estimate_duration).Also on this endpoint, some fields look like they could be populated from data that already arrives in
buried/reportbut aren't:sizeis1for files not in the store —buried/reportcarries the realgcode_sizeestimated_timeisnull—buried/reportcarriesestimate_durationIs querying arbitrary files out of scope, or should it look the file up in the store?
2.
total_layers/curr_layernot reset at end of print_on_printresets several fields onstoped/canceledbut nottotal_layers/curr_layer;finishedresets onlyfile_ready. So after a print finishes, querying the metadata still returns the previous job's values until a newburied/reportarrives.At the start of the next print there's a window (
print/reportwithout layer keys, beforeburied/report) where the endpoint serves the previous job's layer count / object height. Is this expected?3.
progressnon-monotonic during pre-print phasesDuring
checking/auto_leveling/preheatingthe printer reports aprogressthat tracks the prep phase and resets to 0 when printing starts. It's forwarded tovirtual_sdcard.progress/display_status.progress, which in Moonraker is usually treated as monotonic (fraction of file printed).(Mapping
preheating->printingitself seems fine / matches Klipper, just asking about the progress value.)Thanks for the precise writeup, @fmontagna — genuinely useful to get "is this intended?" framed this clearly instead of a vague bug report. Went through all three carefully:
1.
filenameparameter — you're right that something's off here, though I want to correct the framing slightly: the parameter isn't ignored outright,_build_file_metadata()does look up the requested file's own row in the GCode store. The actual bug is more subtle:layer_height/total_layers/estimated_timewere read from live in-memory state first, and only fell back to the queried file's own stored row when the live value happened to be falsy. So querying metadata for any file other than the currently/last-tracked job could leak that job's layer count / estimated time into the response. Fixed — live state is now only consulted when the query targets that same tracked file; any other filename (including a nonexistent one) relies solely on its own record.On
size/estimated_timespecifically: I couldn't find anyburied/reportMQTT topic,gcode_size, orestimate_durationfield anywhere in this bridge's code or MQTT subscriptions (the topics we subscribe to aretempature/report,print/report,info/report,file/report,multiColorBox/report,light/report,skip/report). Could you say more about where you observedburied/report? If it's from raw MQTT sniffing on a different firmware version, or from something moonraker-obico surfaces internally, that'd help me figure out whether it's something we should be subscribing to as well. Thesize: 1fallback (gf.get("size_bytes") or 1) for files without a store entry is a real, separate rough edge that I'd like to fix regardless — it's just not clear yet what a reliable live-value source for it would be without a print sliced/uploaded through the bridge.2.
total_layers/curr_layernot reset — confirmed, and it turned out to be worse than just those two fields: a successful finish (state=finished) only ever clearedfile_ready, while stop/cancel correctly reset progress, filename, duration, and everything else. So after a normal completed print, the metadata endpoint (and other stale fields) could keep serving the just-finished job's data indefinitely, not just its layer count. Both_on_printand_on_infonow do a full reset (including layer fields) on all three terminal states (finished/stoped/canceled).3. Non-monotonic progress during pre-print phases — confirmed.
preheating/auto_leveling/checking/updated/initall map to Klipper'sprintingstate for compatibility, but the printer's own progress value during those phases was passed straight through tovirtual_sdcard.progress/display_status.progress. That value no longer gets forwarded during those phases — real print progress only starts flowing once the printer reportsprinting.All three fixes committed locally on
nightlywith a dedicated test suite, going out with the next nightly build — still hoping to hear back on theburied/reportquestion above before I take a swing at thesizefallback.