amorfo77/parsedmarc
1
0
Fork 0
mirror of https://github.com/domainaware/parsedmarc.git synced 2026-08-16 04:03:19 +00:00
Code Issues Projects Releases Wiki Activity

Clarify that Nested() on auth-result fields is in-memory shape only

Browse Source 
Copilot flagged that _AggregateReportDoc declares dkim_results and
spf_results with Nested(...) while the create_indexes comment insists
the stored mapping must stay dynamic `object`. Both are true: the
Nested declaration only shapes the DSL's in-memory document building
and is never installed as a mapping, because create_indexes skips
Index.document() registration. Say so at both sites, in both backends,
so nobody "fixes" the mismatch by registering the mapping — which
would install real nested mappings and blank the dashboards.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Sean Whalen
2026-07-24 22:12:41 -04:00
co-authored by Claude Fable 5
parent e30b0ab9ec
commit dce4ed16ee
2 changed files with 20 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
parsedmarc/elastic.py
+10 -2
View File
@@ -227,6 +227,11 @@ class _AggregateReportDoc(Document):
header_from = Text()
envelope_from = Text()
envelope_to = Text()
# Nested(...) on the two auth-result fields below is only the DSL's
# in-memory document shape; it is never installed as a mapping.
# create_indexes() deliberately skips Index.document() registration so
# these fields stay dynamic-mapped as plain `object` in the cluster
# (see the comment there and issue #169).
dkim_results = Nested(_DKIMResult)
spf_results = Nested(_SPFResult)
# One "{selector} / {domain} / {result}" (DKIM) or "{scope} / {domain} /
@@ -558,8 +563,11 @@ def create_indexes(names: list[str], settings: dict[str, Any] | None = None):
# tables, and Grafana's nested bucket aggregation (9.4+) lacks
# reverse_nested for parent-level metrics like message_count —
# so the dynamic `object` mapping produced by a bare create is
# load-bearing for the shipped dashboards. See issue #169 and
# the *_combined fields on _AggregateReportDoc.
# load-bearing for the shipped dashboards. _AggregateReportDoc
# still declares dkim_results/spf_results with Nested(...), but
# that is only the DSL's in-memory shape for building documents
# — it is never installed as a mapping. See issue #169 and the
# *_combined fields on _AggregateReportDoc.
if not index.exists():
logger.debug("Creating Elasticsearch index: {0}".format(name))
if effective_settings:
parsedmarc/opensearch.py
+10 -2
View File
@@ -185,6 +185,11 @@ class _AggregateReportDoc(Document):
header_from = Text()
envelope_from = Text()
envelope_to = Text()
# Nested(...) on the two auth-result fields below is only the DSL's
# in-memory document shape; it is never installed as a mapping.
# create_indexes() deliberately skips Index.document() registration so
# these fields stay dynamic-mapped as plain `object` in the cluster
# (see the comment there and issue #169).
dkim_results = Nested(_DKIMResult)
spf_results = Nested(_SPFResult)
# One "{selector} / {domain} / {result}" (DKIM) or "{scope} / {domain} /
@@ -476,8 +481,11 @@ def create_indexes(names: list[str], settings: dict[str, Any] | None = None):
# tables, and Grafana's nested bucket aggregation (9.4+) lacks
# reverse_nested for parent-level metrics like message_count —
# so the dynamic `object` mapping produced by a bare create is
# load-bearing for the shipped dashboards. See issue #169 and
# the *_combined fields on _AggregateReportDoc.
# load-bearing for the shipped dashboards. _AggregateReportDoc
# still declares dkim_results/spf_results with Nested(...), but
# that is only the DSL's in-memory shape for building documents
# — it is never installed as a mapping. See issue #169 and the
# *_combined fields on _AggregateReportDoc.
if not index.exists():
logger.debug("Creating OpenSearch index: {0}".format(name))
if settings is None: