fitzee commented on code in PR #44465:
URL: https://github.com/apache/superset/pull/44465#discussion_r4066845175


##########
docs/admin_docs/configuration/alerts-reports.mdx:
##########
@@ -478,6 +478,37 @@ There are many reasons that reports might not be working. 
Try these steps to che
 
 ### Blank PDF or PNG captures
 
+Final screenshot bytes are validated independently of the capture 
implementation.
+PDF delivery requires evidence that the exact PDF was assembled from validated
+images during this execution. Capture rejection remains sticky for the 
execution;
+substituting another attachment cannot clear it. Detection is a heuristic, not 
a
+guarantee that every chart contains correct data. Uniform fills are rejected
+regardless of colour or theme. A small label or logo does not override a blank
+classification. Extremely sparse legitimate output can therefore be rejected;
+a solid-fill KPI without visible structure has no pixel-only exemption.
+
+Chart error and empty states are terminal for readiness, but a rendered error 
is
+not successful chart data. Logs distinguish `rendered_holders`, 
`empty_holders`,
+`error_holders` and `semantic_success`; `report_semantic_status` warns when a
+completed capture includes terminal chart errors.

Review Comment:
   Fixed in f4ef4cc50fd26c02e4963240c523e285019a4541. The docs explicitly say 
recognized empty/error states satisfy the readiness wait and do not themselves 
trigger capture retries or block delivery. Error-state delivery is 
distinguished from successful chart data.
   



##########
docs/admin_docs/configuration/alerts-reports.mdx:
##########
@@ -478,6 +478,37 @@ There are many reasons that reports might not be working. 
Try these steps to che
 
 ### Blank PDF or PNG captures
 
+Final screenshot bytes are validated independently of the capture 
implementation.
+PDF delivery requires evidence that the exact PDF was assembled from validated
+images during this execution. Capture rejection remains sticky for the 
execution;
+substituting another attachment cannot clear it. Detection is a heuristic, not 
a
+guarantee that every chart contains correct data. Uniform fills are rejected
+regardless of colour or theme. A small label or logo does not override a blank
+classification. Extremely sparse legitimate output can therefore be rejected;
+a solid-fill KPI without visible structure has no pixel-only exemption.
+
+Chart error and empty states are terminal for readiness, but a rendered error 
is
+not successful chart data. Logs distinguish `rendered_holders`, 
`empty_holders`,
+`error_holders` and `semantic_success`; `report_semantic_status` warns when a
+completed capture includes terminal chart errors.
+
+This is not a guarantee that every delivered image contains useful data. A 
large
+enough title or logo can still exceed the detector's content thresholds while 
the
+rest of the page is incomplete; removing the sparse-content override does not
+solve that general limitation. Recognized terminal chart errors are 
capture-ready
+and may be delivered with a warning, provided the
+image passes visual validation. Operators requiring all charts to contain data
+must not treat this policy as that guarantee. The strict invariant is that an

Review Comment:
   Fixed in f4ef4cc50fd26c02e4963240c523e285019a4541. Consolidated the 
heuristic limitation into one paragraph, preserving the fail-closed invariant 
and explaining that a sufficiently large title/logo can exceed the content 
threshold without a special exemption.
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to