Enum properties are silently missing from GET element properties — dead "GEnum" match arm

[srperens]

Description

PipelineManager::get_element_property in gst/pipeline/properties.rs dispatches on the property's GType name, and its enum arm matches the literal string "GEnum":

let type_name = pspec.value_type().name();

let value = match type_name.to_string().as_str() {
    "gchararray" => { ... }
    "gboolean" => { ... }
    ...
    "GEnum" => {
        // Get enum as string
        ...
    }
    _ => {
        return Err(PipelineError::InvalidProperty {
            ...
            reason: format!("Unsupported property type: {}", type_name),
        });
    }
};

An element's enum property reports its own GType name — GstVideoTestSrcPattern, GstDeinterlaceModes, GstRTSPLowerTrans — never "GEnum". So the arm is dead and every enum property falls through to the _ arm.

The pad version of the same function, a few hundred lines down in the same file, gets it right:

_ => {
    // Check if it's an enum type
    if pspec.value_type().is_a(glib::Type::ENUM) {

Expected Behavior

GET /api/flows/{flow_id}/elements/{element_id}/properties returns enum properties (as their nick string, matching the pad path), and .../properties/{name} for a single enum property returns its value.

Actual Behavior

get_element_property returns InvalidProperty { reason: "Unsupported property type: GstVideoTestSrcPattern" }. get_element_properties swallows that — it does if let Ok(value) = self.get_element_property(...) — so enum properties are silently absent from the response rather than reported as an error. A client reading back videotestsrc's pattern gets a map that simply does not contain it.

Steps to Reproduce

1. Start a flow containing a videotestsrc.
2. GET /api/flows/{flow_id}/elements/{element_id}/properties.
3. pattern is missing from the returned map, while num-buffers, is-live and the rest are present.

Additional Context

Read-path only — there is no panic in it, which is why #724 deliberately left it alone (it would change what the API returns, so it wants its own PR and its own openapi/contract consideration). Filed so it does not get lost.

The fix is presumably to replace the "GEnum" arm with the value_type().is_a(glib::Type::ENUM) check the pad path already uses. Note the two paths currently disagree on the representation — the element path's dead arm was written to return enum_value.name() (e.g. GST_VIDEO_TEST_SRC_SNOW), the pad path returns enum_val.nick() (e.g. snow). Nicks are what the write path accepts, so they are the ones worth converging on.

Environment

• OS: macOS 26.6.2 (arm64)
• Strom version: 0.6.8
• GStreamer version: 1.28.6

[srperens]

CONFIRMED, and the read path has a second consumer the report does not name.

backend/src/gst/pipeline/properties.rs:261 — "GEnum" => { — is dead; the pad reader gets it right below — backend/src/gst/pipeline/properties.rs:477 — if pspec.value_type().is_a(glib::Type::ENUM) {

Nick is the right target for a reason beyond consistency: the write path takes the string arm first and hands it to GStreamer's deserializer, which understands nicks — nick() round-trips through a PUT, name() does not.

The second consumer. get_block_properties_inner reads live exposed properties one at a time — backend/src/state.rs:2052 — let raw = match manager — and skips a failing read with a trace!. A live block property mapped to an enum is therefore absent from block reads too, not only from GET .../properties, where backend/src/gst/pipeline/properties.rs:340 — if let Ok(value) = self.get_element_property(element_id, &name) { — swallows it.

Option A (fix the arm). Replace the "GEnum" arm with the pad path's is_a check, returning nick(). Smallest diff; the two paths agree.

Option B (one reader). The ~70-line type dispatch exists twice, once per path; extract one function both call. That duplication is what let this diverge unnoticed, so B removes the class, not the instance. Larger, and must reconcile two InvalidProperty shapes.

Radius — SHARED: one module changed, two consumers start returning values they never did. No endpoint or StromEvent shape changes — the map gains keys — so openapi should not move. Client code reading an absent key as "unset" now sees a value.

Guarding test — in properties.rs's #[cfg(test)] module: build a videotestsrc, read pattern, assert the nick form and not the GST_VIDEO_TEST_SRC_* name form, then write "snow" and read it back. Confirm its package is in .github/workflows/ci.yml rather than assuming it.

Recommendation — B. A leaves two copies of the dispatch, and this issue is what that costs.

Ask: Option A (fix the dead arm in place) or Option B (one shared reader)? Reply /agent-fix A --accept-radius SHARED or /agent-fix B --accept-radius SHARED; other phrasing needs a human to interpret first.

Confidence: HIGH

[srperens]

Re-evaluated against f612b4a (current main, which now carries #724) and checked the glib/GStreamer semantics with a throwaway test rather than by reading — GStreamer 1.28.6, gstreamer 0.25.3, glib 0.22.7, macOS arm64. Still CONFIRMED, but two things in the report and in my earlier triage are wrong, and they change the answer to the ask.

The dead arm is dead as described. pspec.value_type().name() on videotestsrc.pattern is GstVideoTestSrcPattern, so backend/src/gst/pipeline/properties.rs:261 — "GEnum" => { — never matches and the property falls to _, where backend/src/gst/pipeline/properties.rs:340 — if let Ok(value) = self.get_element_property(element_id, &name) { — drops it.

Correction 1 — the pad path does not get it right. It picks the right branch and then reads the wrong way. backend/src/gst/pipeline/properties.rs:480 — if let Ok(enum_value) = value.get::<i32>() { — and glib's checker is strict (g_type_check_value_holds); an enum GValue is not is_a G_TYPE_INT:

get::<i32>() = Err("Value type mismatch. Actual GstVideoTestSrcPattern, requested gint")

So get_pad_property returns InvalidProperty { reason: "Failed to read enum value for type: …" } for every enum pad property — compositor sink_%u.operator, for one. Option A as I stated it — port the pad path's is_a check — would fix nothing. The read call has to change too, not just the dispatch.

Correction 2 — enum_value.name() is not the C identifier. GStreamer's enum tables put the human description in value_name, so the dead arm was written to return this:

EnumValue name="SMPTE 100% color bars" nick="smpte"

Not GST_VIDEO_TEST_SRC_SMPTE. The conclusion holds and gets stronger: nick is the only form that round-trips. #724's write path hands strings to gst_value_deserialize, which took "snow" and rejected "GST_VIDEO_TEST_SRC_BALL" in the same test. Nick is also what the block layer already uses for its own enum values (decklink_input.stream_mode = audio_video, video, audio).

Recommendation — B, with gst_value_serialize as the fallback arm. One shared reader is still right; the duplication is what let the two paths drift. But rather than writing a third enum branch inside it, let the fallback go through GstValueExt::serialize() — the mirror of the deserialized_value helper #724 put on the write path. Measured on the same run:

enum   -> "smpte"
flags  -> "GST_RTSP_LOWER_TRANS_UDP+GST_RTSP_LOWER_TRANS_UDP_MCAST+GST_RTSP_LOWER_TRANS_TCP"
caps   -> "ANY"

That returns the nick for enums and closes the same hole for flags, caps, fractions and structures, which otherwise keep falling out as "Unsupported property type" on both paths after an enum-only fix. Read and write end up symmetric: the string the API returns is a string the API accepts. The two InvalidProperty shapes reconcile by having the shared reader return Result<PropertyValue, String> and each caller wrap its own identity (element_id vs element_id:pad_name).

Radius — SHARED, unchanged. No endpoint or StromEvent shape moves; the map gains keys, so openapi.json should not need regenerating (worth asserting with the snapshot test rather than assuming). Consumers are GET .../properties, GET .../properties/{name} and the MCP get_element_properties tool. The GUI does not read this path — frontend/src/palette.rs:25 — element_properties_cache: HashMap<String, ElementInfo>, — is the element registry, not a live read.

The second consumer I named is latent today. I went through all 48 live: true exposed properties: every one is numeric or bool (volume, mute, panorama, th, f-*, g-*, q-*, enabled, amplification, …) plus the synthetic offset_ms. None maps to an enum, so backend/src/state.rs:2053 — .get_element_property(&full_element_id, &exposed.mapping.property_name) — loses nothing at present. It is a trap for the next enum-valued live property, not a symptom anyone sees now. Worth saying in the PR body; not worth claiming as user-visible.

Guarding test — an integration test in the shape of backend/tests/pipeline_start_failure_test.rs: build a flow with videotestsrc through PipelineManager::new, read pattern, assert "smpte" and explicitly not "SMPTE 100% color bars", then write "snow" and read it back. Cover the pad path in the same test with compositor sink_%u.operator, so Correction 1's branch is actually exercised — an element-only test leaves it broken and green. videotestsrc comes from gstreamer1.0-plugins-base and compositor from gstreamer1.0-plugins-bad, both already in the package list of every test job in .github/workflows/ci.yml, so this runs in CI rather than skipping. Reverting either half fails it.

Ask (restated — the A/B question above is void, A does not fix the bug). Fix scope:

• B — one shared reader for the element and pad paths, fallback via gst_value_serialize. Enums return their nick; flags, caps, fractions and structures start reading too.
• B-narrow — same shared reader, but the fallback handles enums only and everything else keeps returning "Unsupported property type", leaving flags and caps for a separate issue.

Reply /agent-fix B --accept-radius SHARED or /agent-fix B-narrow --accept-radius SHARED; other phrasing needs a human to interpret first.

Confidence: HIGH