| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Generate the default Android installation ID after programmatic configuration and only when the resolved user information policy allows it. Preserve custom distinct IDs and keep legacy behavior when Data Collection is absent. Refs #5666 Co-Authored-By: Claude <noreply@anthropic.com>
Make KeyValueCollectionBehavior JavaBean-bindable so Spring Boot properties correctly configure cookie, header, and query policies. Cover binding across all supported Spring Boot generations. Co-Authored-By: Claude <noreply@anthropic.com>
📲 Install BuildsAndroid
|
Sorry, something went wrong.
Performance metrics 🚀
Baseline results on branch: feat/data-collection-session-replay-network-optionsStartup times
App size
Previous results on branch: fix/data-collection-spring-bindingStartup times
App size
|
Sorry, something went wrong.
…to fix/data-collection-android-installation-id
…ata-collection-spring-binding
Use the canonical URL query parameter property name in Spring Boot 2, 3, and 4 binding coverage. Refs #5666 Co-Authored-By: Claude <noreply@anthropic.com>
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. This PR will not appear in the changelog. 🤖 This preview updates automatically when you update the PR. |
Sorry, something went wrong.
…to fix/data-collection-android-installation-id
…ata-collection-spring-binding
…ata-collection-spring-binding
…to fix/data-collection-android-installation-id
…ata-collection-spring-binding
There was a problem hiding this comment.
LGTM 👍
Sorry, something went wrong.
…to fix/data-collection-android-installation-id
This reverts commit b27d61d.\n\nKeep generated installation IDs independent of the userInfo policy. Restore\ndefault generation before programmatic configuration so applications can\ncontinue clearing the distinct ID in the configuration callback.\n\nRefs #5666\n\nCo-Authored-By: Claude <noreply@anthropic.com>
…ata-collection-spring-binding
Merge the conflict-resolved cookie policy through the remaining stacked branches. Co-Authored-By: Claude <noreply@anthropic.com>
Merge the latest changes from the preceding Data Collection branch. Co-Authored-By: Claude <noreply@anthropic.com>
Create key-value fallback behaviors for each resolver lookup so mutations cannot leak across cookie, query parameter, and header policies. Refs #5666 Co-Authored-By: Claude <noreply@anthropic.com>
Merge the latest changes from the preceding Data Collection branch. Co-Authored-By: Claude <noreply@anthropic.com>
Propagate the corrected OkHttp Set-Cookie fixture through the Data Collection PR stack. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
LGTM!
Sorry, something went wrong.
Bring the latest base branch fixes into this stacked branch. Co-Authored-By: Claude <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
PR Stack (Data Collection)
📜 Description
Make KeyValueCollectionBehavior JavaBean-bindable so Spring Boot can configure Data Collection policies for cookies, URL query parameters, and request/response headers.
Add a public no-argument constructor with the default deny-list behavior and setters for mode and terms. The existing off, denyList, and allowList factories remain available, and terms continue to be defensively copied into an immutable list.
💡 Motivation and Context
Spring Boot could bind scalar Data Collection fields but silently ignored nested key-value policies because KeyValueCollectionBehavior only exposed private construction and immutable fields. A scalar property could therefore make the namespace explicit while the requested cookie, query, or header restriction was not applied.
Refs #5666
💚 How did you test it?
📝 Checklist
🔮 Next steps
Add the remaining external and Android manifest Data Collection configuration paths.
#skip-changelog