Skip to content

Conversation

scouten-adobe
Copy link
Collaborator

@scouten-adobe scouten-adobe commented Sep 24, 2025

Settings are now snapshotted at public API surfaces and passed through all layers below.

Note related work from @ok-nick in #1447 and further work likely in #1454.

@scouten-adobe scouten-adobe self-assigned this Sep 24, 2025
Copy link

codecov bot commented Sep 24, 2025

Codecov Report

❌ Patch coverage is 92.90323% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.04%. Comparing base (c4fc7a6) to head (7aeb9c3).
⚠️ Report is 7 commits behind head on main.

Files with missing lines Patch % Lines
sdk/src/builder.rs 88.73% 8 Missing ⚠️
sdk/src/reader.rs 56.25% 7 Missing ⚠️
sdk/src/assertions/bmff_hash.rs 33.33% 2 Missing ⚠️
sdk/src/claim.rs 90.47% 2 Missing ⚠️
sdk/src/identity/identity_assertion/assertion.rs 87.50% 2 Missing ⚠️
sdk/src/crypto/time_stamp/http_request.rs 75.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1444      +/-   ##
==========================================
- Coverage   78.41%   78.04%   -0.38%     
==========================================
  Files         162      162              
  Lines       39515    40017     +502     
==========================================
+ Hits        30986    31230     +244     
- Misses       8529     8787     +258     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link

codspeed-hq bot commented Sep 24, 2025

CodSpeed Performance Report

Merging #1444 will improve performances by 12.62%

Comparing scouten/settings-not-thread-local (7aeb9c3) with main (8bc2a1d)1

Summary

⚡ 16 improvements
⏩ 2 skipped2

Benchmarks breakdown

Benchmark BASE HEAD Change
read 100kb-signed.gif (with manifest) 6.1 ms 4.6 ms +32.56%
read 100kb-signed.jpg (with manifest) 13.5 ms 12 ms +12.62%
read 100kb-signed.mp3 (with manifest) 6.5 ms 5 ms +29.57%
read 100kb-signed.mp4 (with manifest) 6.4 ms 4.9 ms +30.82%
read 100kb-signed.png (with manifest) 13.6 ms 12.1 ms +12.76%
read 100kb-signed.svg (with manifest) 10.1 ms 8.6 ms +17.51%
read 100kb-signed.tiff (with manifest) 4.3 ms 2.8 ms +53.84%
read 100kb-signed.wav (with manifest) 6.2 ms 4.7 ms +31.63%
sign 100kb gif 6.5 ms 3.8 ms +69.48%
sign 100kb jpeg 7.3 ms 5.3 ms +37.28%
sign 100kb mp3 7 ms 4.6 ms +51.49%
sign 100kb mp4 9.9 ms 5.7 ms +73.43%
sign 100kb png 7.8 ms 5.7 ms +37.12%
sign 100kb svg 19.6 ms 17 ms +14.78%
sign 100kb tiff 4.8 ms 2.1 ms ×2.3
sign 100kb wav 6.9 ms 4.9 ms +42.83%

Footnotes

  1. No successful run was found on main (4e9c3f2) during the generation of this report, so 8bc2a1d was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

  2. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@scouten-adobe scouten-adobe marked this pull request as ready for review October 1, 2025 02:45
@scouten-adobe scouten-adobe added the check-release Add this label to any PR to invoke a larger suite of tests. label Oct 1, 2025
let mut validation_log = StatusTracker::default();

let settings = Settings::default();
// ^^ TO REVIEW: Is there a reason we'd need non-default settings here?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there actually a setting already that changes things in here? If so, it could be useful to investigate why that setting came to be - might answer the question as side-effect.

Copy link
Contributor

@ok-nick ok-nick Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will be a problem, see here:
#1444 (comment)

// "builder.auto_opened_action.source_type",
// );
//
// ... which omits the ".actions" node after "builder"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My 2 cents: It would be good to keep the settings structured. The missing actions node feels like a typo to me?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. What I don't know is how to repair the test in question. @gpeacock?

Copy link
Contributor

@ok-nick ok-nick Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The source type is only necessary for the c2pa.created action. We should be able to safely remove this from the test_settings.toml that the test uses.

@gpeacock for confirmation

use common::test_signer;

#[test]
#[ignore = "See discussion in builder.rs near line 1190"]
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gpeacock please review this before we merge.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ok-nick ok-nick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving lots of reviews to track progress.

Comment on lines 165 to 166
// TO DO BEFORE MERGE: Passing `verify` may be redundant now that we're
// passing settings.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: internal

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +189 to +190
// TO DO BEFORE MERGE: Passing `verify` may be redundant now that we're
// passing settings.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: internal

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +59 to +60
// TO REVIEW: I think in this case, we're doing structural validation of
// time stamps but not trust validation. If so, the below is correct. (I think.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: internal

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, following the code path we explicitly set CertificateTrustPolicy::passthrough which stops before trust checks occur. A bigger question is if we need settings here at all versus passing verify_trust through the passthrough field of CertificateTrustPolicy.

Comment on lines +44 to +45
let settings = crate::settings::get_settings().unwrap_or_default();
// TO DO BEFORE MERGE? Pass Settings in here?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: internal

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 1696 to 1699
let settings = Settings::default();
// ^^ TO REVIEW: Is there a reason we'd need non-default settings here?
// If so, that means we hae to rework CAIReader and CAIWriter traits
// to take a &Settings arg and that is a pretty huge change.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Settings in the Store constructors are only used for configuring trust. In this scenario we are only using the Store to reconstruct the split manifest stores in BMFF, the trust is validated with a higher-level Store. It does feel wrong to create default settings and pass it in as a parameter here, but I don't think it'll be a problem for the time being.

cc @mauricefisher64 to confirm.

let mut validation_log = StatusTracker::default();

let settings = Settings::default();
// ^^ TO REVIEW: Is there a reason we'd need non-default settings here?
Copy link
Contributor

@ok-nick ok-nick Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will be a problem, see here:
#1444 (comment)

@ok-nick ok-nick mentioned this pull request Oct 2, 2025
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
check-release Add this label to any PR to invoke a larger suite of tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants