Skip to content

Migration scripts - POC - #1

Merged
constantine2nd merged 1 commit into
developfrom
migration-scripts
Apr 4, 2019
Merged

constantine2nd merged 1 commit into
developfrom
migration-scripts

Conversation

@constantine2nd

Copy link
Copy Markdown
Owner

No description provided.

@constantine2nd
constantine2nd merged commit 6c83857 into develop Apr 4, 2019
constantine2nd pushed a commit that referenced this pull request Dec 12, 2019
…s properly

#1 create the account access for each custom view and user
#2 create the account access for each system view and user
#3 create account holder for each account
constantine2nd pushed a commit that referenced this pull request Sep 13, 2022
by using --mount=type=cache for mvn dependencies
constantine2nd pushed a commit that referenced this pull request Jan 6, 2026
Bug #1: getActiveCallLimitsByConsumerIdAtDate ignored the date parameter
- Always used LocalDateTime.now() instead of the provided date
- Broke queries for future dates
- API endpoint /active-rate-limits/{DATE} was non-functional

Bug #2: Hour-based caching created off-by-minute query bug
- Query truncated to start of hour (12:00:00)
- Rate limits created mid-hour (12:01:47) were not found
- Condition: fromDate <= 12:00:00 failed when fromDate = 12:01:47

Solution:
- Use the actual date parameter in getActiveCallLimitsByConsumerIdAtDate
- Query full hour range (12:00:00 to 12:59:59) instead of point-in-time
- Ensures rate limits created anytime during the hour are found

Fixes test: RateLimitsTest.scala:259 - aggregated rate limits
Expected: 15 (10 + 5), Got: -1 (not found) → Now returns: 15 ✅

See RATE_LIMITING_BUG_FIX.md for detailed analysis.
constantine2nd pushed a commit that referenced this pull request Jan 6, 2026
…zone

Bug #1: getActiveCallLimitsByConsumerIdAtDate ignored date parameter
- Used LocalDateTime.now() instead of provided date parameter
- Broke queries for future dates
- API endpoint /active-rate-limits/{DATE} was non-functional

Bug #2: Hour-based caching caused off-by-minute timing bug
- Query truncated to start of hour (12:00:00)
- Rate limits created mid-hour (12:01:47) not found
- Condition: fromDate <= 12:00:00 failed when fromDate = 12:01:47

Bug #3: Timezone mismatch between system and tests
- Code used ZoneId.systemDefault() (CET/CEST)
- Tests use ZoneOffset.UTC
- Caused hour boundary mismatches

Solution:
- Use actual date parameter in getActiveCallLimitsByConsumerIdAtDate
- Query full hour range (12:00:00 to 12:59:59) instead of point-in-time
- Use UTC timezone consistently
- Add debug logging for troubleshooting

Note: Test still failing - may be cache or transaction timing issue.
Further investigation needed.

See RATE_LIMITING_BUG_FIX.md for detailed analysis.
constantine2nd added a commit that referenced this pull request May 25, 2026
…refix

Drop the `prefix == "v6.0.0"` guard that Http4sResourceDocs inherited
from the original Lift setup (only ResourceDocs600 registered the
OpenAPI 3.1 routes). The handlers depend solely on the requested-API-
version path segment (`requestedApiVersionString`), not on the URL
prefix — `implForPrefix(prefix)` already falls back to `ImplDefault`
for non-v6 prefixes, and `isVersion4OrHigher` is hardcoded `true`
inside the handlers because the OpenAPI converter always consumes the
v4-shape input. The prefix guard added no value, just surprised
callers hitting `/obp/v5.1.0/resource-docs/v5.1.0/openapi` with a Lift
404 fall-through.

After this change:

  GET /obp/{ANY_PREFIX}/resource-docs/{API_VERSION}/openapi      → 200 JSON
  GET /obp/{ANY_PREFIX}/resource-docs/{API_VERSION}/openapi.yaml → 200 YAML

Tests: SwaggerDocsTest gains two scenarios that hit /openapi and
/openapi.yaml under the v5.1.0 URL prefix and assert 200. The existing
v6.0.0-prefix scenarios continue to pass (12 total now).

Step #1 from the as-is overview's to-do list. Closes a small but
real bridge fall-through that the audit endpoint had surfaced as a
candidate; reduces the surface area Lift still has to handle.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant