Notification publisher configuration cannot be read after upgrade from 3.8.0 to 4.1.0
See original GitHub issueCurrent Behavior:
After migrating from 3.8.0 to 4.1.0 the notification publisher configuration in NOTIFICATIONRULE.PUBLISHER_CONFIG
cannot be read by the application (at least for the email publisher). In 3.8.0 this is stored as a large object in the database while 4.1.0 stores it directly in the column. Other large objects like license texts or vulnerability descriptions work.
Steps to Reproduce:
- Setup a database and configure an email notification with destination address with 3.8.0
- Run the migration script
- Run the 4.1.0 API server
Expected Behavior:
I expect the configuration to be read and visible in the frontend.
Environment:
- Dependency-Track Version: 4.1.0
- Distribution: Executable WAR
- BOM Format & Version:
- Database Server: PostgreSQL
- Browser: Firefox
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (4 by maintainers)
Top Results From Across the Web
Release notes & updates – Azure CLI - Microsoft Learn
Learn about the latest Azure Command-Line Interface (CLI) release notes and updates for both the current and beta versions of the CLI.
Read more >Change Log - Dependency-Track
Upgrade Notes: The value of the scanner.analysis.cache.validity.period configuration property will be reset to 12 hours during the automated upgrade.
Read more >Blog - Apache Cordova
By passing down all attribute data, Cordova-Common no longer needs to be updated for adding and supporting new platform attributes.
Read more >Firebase Apple SDK Release Notes - Google
Added notification support for iOS 16 simulators on Xcode 14. ... Updated GTMSessionFetcher dependency specifications to enable support for the compatible ...
Read more >Docker Compose release notes
Updated Docker Engine API to restore compatibility with Golang 1.18 needed ... Added ssh config to the build options when building an image...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Digging deeper I discovered another problem with the CLOBs and PostgreSQL. The extension lo provides as a rationale that the JDBC driver assumes that BLOBs are stored in the tables. Modifying or deleting them is assumed to remove the large object. In the database, however, large objects are separate entities that are just referenced from the tables and have to be deleted separately. Otherwise they just remain as unreferenced objects in the database. Indeed I see this for the CLOB columns in our installation. Therefore switching to storing these in the table seems to be the most sensible choice to me.
This affects the following columns from Dependency-Track and one from Alpine:
The CLOB columns for NotificationPublisher.template and License.text, .template, .header, .comment are resynchronized on system start and thus automatically converted from their CLOB representation.
The pull request should rewrite the necessary columns and remove all large objects to also remove the orphaned ones.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.