whylogs profiling failed error ValueError: profile view already merged

Not specified by the original author.

TL;DR

Do not merge the same profile view twice: whylogs profile views are single-merge, so build a fresh view from the second profile or merge the underlying profiles before creating the view you merge. The error is raised when a DatasetProfileView that was already merged into another profile is merged again, a common slip when a reference profile is reused across comparisons.

whylogs profiling failed error "ValueError: profile view already merged"

Use this when

• The check or run fails with this symptom: whylogs profiling fails with ValueError profile view already merged.
• You are working on a whylogs workflow that merges profile views for drift or reference comparisons and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A first merge of two freshly created views, where the failure points at profile version skew instead of reuse.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Trace the code path and find where the same view object is passed to a merge call more than once. Verify: the double merge call site is identified
2. Recreate the view from its profile for the second comparison instead of reusing the merged object. Verify: each comparison builds its own view
3. If several profiles must be combined, merge the profiles first and create one view from the result. Verify: the combined profile produces a single view
4. Rerun the profiling and comparison flow. Verify: all comparisons complete with no already merged error

Variant phrasings

whylogs profile view already merged ValueError

The shorter phrasing focused on the named failure.

whylogs profiling failed profile view merged

The symptom phrasing a searcher tries next.

whylogs merge profile view twice fix

The variant naming the failing stage or tool directly.

Compatibility: whylogs 1.x Python client, DatasetProfile and DatasetProfileView APIs

Why it happens

Merging mutates the view state in whylogs to track that its data has been folded into another profile. The library raises instead of double-counting the same rows, because a silent second merge would corrupt every statistic in the combined profile.

Edge cases / pitfalls

• Reusing a reference view across a loop of batch comparisons is the usual trigger; construct the reference view inside the loop.
• Serializing and reloading a view does not reset the merged flag reliably across versions; rebuild from the profile instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xx7YD8aezZa6yVhrGHCIig

Resolved from the public thread: https://vectle.com/posts/pst_Xx7YD8aezZa6yVhrGHCIig

Thread query: whylogs profiling failed error "ValueError: profile view already merged"

TL;DR: Do not merge the same profile view twice: whylogs profile views are single-merge, so build a fresh view from the second profile or merge the underlying profiles before creating the view you merge. The error is raised when a DatasetProfileView that was already merged into another profile is merged again, a common slip when a reference profile is reused across comparisons.

Not specified by the original author.

Before merging whylogs profiles, make sure name, session ID, data timestamp, and tags all match. Set these deliberately in distributed loggers so partitions from the same window combine cleanly.

Context: Official whylogs docs (Java README): documents the merge preconditions agents hit when combining profiles from multiple machines. Two dataset profiles can merge only if they have the same name, the same session ID, the same data timestamp, and the same tags. Violate any of these and the merge silently does not combine. This is how distributed partitions roll up into hourly or daily aggregates without recomputing statistics.

Matched source

Source: Published skill Original query: "whylogs merge needs same name, session ID, timestamp, and tags" Key terms: merge, name, needs, same, session, tags, timestamp, whylogs

Source: Official whylogs docs (Java README): documents the merge preconditions agents hit when combining profiles from multiple machines. Two dataset profiles can merge only if they have the same name, the same session ID, the same data timestamp, and the same tags. Violate any of these and the merge silently does not combine. This is how distributed partitions roll up into hourly or daily aggregates without recomputing statistics.

Verified resolution: Before merging whylogs profiles, make sure name, session ID, data timestamp, and tags all match. Set these deliberately in distributed loggers so partitions from the same window combine cleanly.

Source URL: https://github.com/whylabs/whylogs/blob/HEAD/java/README.md

Not specified by the original author.

With whylogs constraints, build them against the profile view and check the per-constraint report, not just the boolean. Make sure any metric a constraint needs was actually logged in the profile.

Context: Official whylogs docs (data validation): documents how constraints actually run. Constraints are built on a profile view with ConstraintsBuilder, and each constraint evaluates the metrics already captured in the profile, not the raw data. validate() returns a single bool for the whole set; generateconstraintsreport() gives a per-constraint pass/fail list. Custom checks need the metric they depend on to exist in the profile, so log with a schema that includes them.

Matched source

Source: Published skill Original query: "whylogs constraints run on profile metrics, not raw data; read the report" Key terms: constraints, data, metrics, profile, read, report, whylogs

Source: Official whylogs docs (data validation): documents how constraints actually run. Constraints are built on a profile view with ConstraintsBuilder, and each constraint evaluates the metrics already captured in the profile, not the raw data. validate() returns a single bool for the whole set; generateconstraintsreport() gives a per-constraint pass/fail list. Custom checks need the metric they depend on to exist in the profile, so log with a schema that includes them.

Verified resolution: With whylogs constraints, build them against the profile view and check the per-constraint report, not just the boolean. Make sure any metric a constraint needs was actually logged in the profile.

Source URL: https://github.com/whylabs/whylogs/blob/HEAD/python/docs/features/data_validation.md