fix(2.4.7): community patterns normalize to scope=global on export and import#225
Merged
Conversation
…d import Pre-2.4.7 the community export pipeline copied the source instance's scope (almost always 'podcast') into the bundle, and the import pipeline used it verbatim. podcast_id was already stripped on export, so the imported row landed as scope='podcast' with podcast_id=NULL -- which the matcher will never match against any podcast. Per-podcast filtering for community patterns happens via tag eligibility in text_pattern_matcher._filter_patterns_by_scope, not via the legacy scope column; scope on community rows should just be 'global'. Fixes: - community_export._strip_metadata forces scope='global' in the bundle regardless of source scope. - pattern_service.import_community_pattern forces scope='global' and None for podcast_id/network_id/dai_platform on every create. - _normalize_community_scope migration in schema.py UPDATEs every source='community' row whose scope is not 'global' OR whose podcast/ network ids are non-null. Stamped via community_scope_revision setting, idempotent. - 11 of 12 committed seed bundles rewritten from scope:podcast to scope:global; manifest regenerated. Tests: +2 in test_community_export covering scope=podcast and scope=network source patterns (with non-null ids on the source to prove they get stripped). +1 in test_pattern_service_rewrite covering import of a legacy bundle that carries scope=podcast + podcast_id + network_id; asserts they all get cleared on insert. 1087 unit tests pass.
Community pattern validationPassed (11)
Validation passed. Ready for review. See |
The workflow pins actions/labeler@v5 but the config still used v4 syntax
('label: [glob]'). v5 rejects that with 'found unexpected type for
label X (should be array of config options)'. The labeler job has been
failing silently on every PR since 2.4.0; the 'pattern' label never
got auto-applied to any of the community-pattern PRs.
Switch to v5 syntax. Same intent: PRs touching patterns/community/**/*.json
get the 'pattern' label.
Community pattern validationPassed (11)
Validation passed. Ready for review. See |
The reason field is the detector's own rationale string -- usually something like 'Brilliant (pattern #309)', but on boundary-extension hits the reviewer's free-text observation lands there instead (e.g., 'Quo (business phone system)' on a Zyn-pattern match that swept up an adjacent Quo ad). Showing it as a bare description below the sponsor badge looks like a contradiction. Prefixing 'Match:' frames it as a note about the detection rather than a second sponsor claim. UI-only tweak. No data shape change.
Community pattern validationPassed (11)
Validation passed. Ready for review. See |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Pre-2.4.7 community patterns were imported with the source instance's scope (almost always
'podcast') butpodcast_idwas stripped on export. Result: scope=podcast rows with podcast_id=NULL that the matcher will never match. User caught it as soon as 2.4.6 imports landed and the Patterns page showed all 12 imports asPodcastscope with no podcast attached.Per-podcast filtering for community rows happens via tag eligibility in
text_pattern_matcher._filter_patterns_by_scope(sponsor_tags vs podcast_tags), not via the legacy scope column. Community rows should just bescope='global'.Changes
community_export._strip_metadataforcesscope='global'in the bundle regardless of source scope.pattern_service.import_community_patternforcesscope='global'andNoneforpodcast_id/network_id/dai_platformon every create. Defensive: a hand-crafted bundle that includes those fields gets them dropped at the boundary._normalize_community_scopemigration inschema.pyre-stamps everysource='community'row to scope='global' and clears stalepodcast_id/network_id. Stamped viacommunity_scope_revisionsetting, idempotent.scope: podcasttoscope: global; manifest regenerated.Version
2.4.7
Test plan
tsc --noEmitclean:latest/:cpufloating)/api/v1/healthreports 2.4.7