Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: attempt initializing the clientRouteRegistry during app init #2371

Merged
merged 3 commits into from
May 3, 2024

Conversation

taefi
Copy link
Contributor

@taefi taefi commented Apr 26, 2024

Description

Attempt initializing the clientRouteRegistry from
RouteUnifyingServiceInitListener, so that before
any request can hit the Security Config filters,
the ClientRouteRegistry is optimistically initialized.
In DEV mode, this attempt can result in no actual
initialization if the file-routes.json has not yet
generated. This attempt is targeting the initialization
of clientRouteRegistry during the DEV mode
redeployments, so that RouteUtils::isRouteAllowed
has a higher chance of dealing with an initialized
registry during the DEV mode.
PROD mode is not affected by this change.

Fixes #2358

Type of change

  • Bugfix
  • Feature

Checklist

  • I have read the contribution guide: https://vaadin.com/docs/latest/guide/contributing/overview/
  • I have added a description following the guideline.
  • The issue is created in the corresponding repository and I have referenced it.
  • I have added tests to ensure my change is effective and works as intended.
  • New and existing tests are passing locally with my change.
  • I have performed self-review and corrected misspellings.

Attempt initializing the clientRouteRegistry from
RouteUnifyingServiceInitListener, so that before
any request can hit the Security Config filters,
the ClientRouteRegistry is optimistically initialized.
In DEV mode, this attempt can result in no actual
initialization if the `file-routes.json` has not yet
generated. This attempt is targeting the initialization
of clientRouteRegistry during the DEV mode redeployments,
so that RouteUtils::isRouteAllowed has a higher chance of
dealing with an initialized registry during the DEV mode.
PROD mode is not affected by this change.

Fixes #2358
Copy link

codecov bot commented Apr 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.14%. Comparing base (6e3d0fb) to head (6e6d530).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2371   +/-   ##
=======================================
  Coverage   95.14%   95.14%           
=======================================
  Files          66       66           
  Lines        4507     4507           
  Branches      644      644           
=======================================
  Hits         4288     4288           
  Misses        178      178           
  Partials       41       41           
Flag Coverage Δ
unittests 95.14% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

@platosha platosha enabled auto-merge (squash) May 3, 2024 10:28
Copy link

sonarcloud bot commented May 3, 2024

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

@platosha platosha merged commit c623163 into main May 3, 2024
15 checks passed
@platosha platosha deleted the taefi/fix-2358 branch May 3, 2024 10:41
@vaadin-bot
Copy link
Collaborator

This ticket/PR has been released with Hilla 24.4.0.beta2 and is also targeting the upcoming stable 24.4.0 version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using routeUtil::isRouteAllowed causes a redirect to /login when redeploying
3 participants