JetBrains / JetBrains/kotless

@Scheduled doesn't work with custom event IDs

Open
#96 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Kotlin
Stars
1.2k
Forks
54
PR merge metrics
No merged PRs in 30d

Description

Originally posted at #82

`@Scheduled` events appear to not work at all on AWS Lambda, when custom event IDs are used.

**Summary:** The short summary is that making scheduled events with custom IDs work (which would be required to not plaster one's AWS account with `merged-X` lambdas), some non-minor refactoring needs to be done.

As far as I can see from my initial investigation, the issue is as follows:

1. When the `LambdaHandler` gets the scheduled event, it contains a resource identifier such as `arn:aws:events:us-east-1:123456789012:rule/general-analyseOffers`. As the `general` prefix is contained in the resource ID, the `EventsStorage` is called to fetch the target function: https://github.com/JetBrains/kotless/blob/415d5b33d2a2047f69eea17c347f03ba27e439f6/dsl/kotless/kotless-lang/src/main/kotlin/io/kotless/dsl/app/events/EventsDispatcher.kt#L23-L27 Note that due to the `substring` part, the resource ID _including the `general` prefix_ is passed as an argument, in this case `general-analyseOffers`.

2. The `EventsStorage` scans for all functions with the `@Scheduled` annotation and notes their ID: https://github.com/JetBrains/kotless/blob/415d5b33d2a2047f69eea17c347f03ba27e439f6/dsl/kotless/kotless-lang/src/main/kotlin/io/kotless/dsl/app/events/EventsStorage.kt#L21-L27 If there is a custom ID, it is used (`analyseOffers` in our case), otherwise an ID is generated that _that includes the `general` prefix_ (e.g. `general-12345`): https://github.com/JetBrains/kotless/blob/415d5b33d2a2047f69eea17c347f03ba27e439f6/dsl/kotless/kotless-lang/src/main/kotlin/io/kotless/dsl/app/events/EventsReflectionScanner.kt#L32-L37

3. The event is now looked up using the prefixed ID (`general-analyseOffers`): https://github.com/JetBrains/kotless/blob/415d5b33d2a2047f69eea17c347f03ba27e439f6/dsl/kotless/kotless-lang/src/main/kotlin/io/kotless/dsl/app/events/EventsStorage.kt#L34 Now, as the Cloudwatch event includes the prefix, but the `EventsStorage` stored the event using the custom ID which does NOT include the prefix (`analyseOffers`), the lookup fails silently and the function is NOT called: https://github.com/JetBrains/kotless/blob/415d5b33d2a2047f69eea17c347f03ba27e439f6/dsl/kotless/kotless-lang/src/main/kotlin/io/kotless/dsl/app/events/EventsDispatcher.kt#L26

And it gets even more complicated. The rule name, that is generated for AWS, is actually modified to fit the AWS naming rules: https://github.com/JetBrains/kotless/blob/415d5b33d2a2047f69eea17c347f03ba27e439f6/engine/src/main/kotlin/io/kotless/gen/GenerationContext.kt#L63-L65 This means that for example `@Scheduled(Scheduled.everyHour, 'com.example.scheduled')` creates a Cloudwatch rule with the name `general-com-example-scheduled`. Thus during event registration, we need to apply the very same rules to the event ID to make sure that when the event is called, the ID lookup will succeed. The issue with that is that at the moment the logic for generating AWS-compatible names is part of the Gradle plugin, but not of the Kotless runtime library. Basically, the code above and its depending classes (mainly `io.kotless.utils.Text` from `kotless-engine`) would have to be moved to a shared library so it can be called both at compile-time and at runtime.

Contributor guide

No contributing guide indexed for this repository

Research direction

Read EventsDispatcher.kt, EventsStorage.kt, EventsReflectionScanner.kt, and GenerationContext.kt to trace how scheduled event IDs are generated, stored, and looked up. Compare the AWS-compatible naming logic and its dependency on io.kotless.utils.Text. Done means custom @Scheduled IDs resolve consistently between registration and Lambda dispatch without breaking generated IDs.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kotlin
Domain
backend, cloud
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.