Lambda Logs API?

[tannerntannern]

I've successfully used this project's lambda-extension library to respond to Invoke and Shutdown events (as the examples demonstrate), but I'm struggling to figure out the best path to use the Lambda Logs API.

My understanding of the lambda-extension library code (as a Rust novice) is that the extension_id is private. In order to use the Lambda Logs API you must subscribe with the extension ID, which you get from registering the extension with the Extensions API. But there's no way that I can see to get the extension_id after registering the extension.

So my question is: If I've used the lambda-extension library as the base for my extension, how can I use the Lambda Logs API if the extension ID is unavailable externally? I could imagine a new lambda-logs library or additional functions in the lambda-extension library, but neither of those options exist currently. What can I do in the meantime without essentially reimplementing the lambda-extension library myself?

[calavera]

oh no! 🤦 that's unfortunate because when I started working on the extensions api, I exposed the ID, but we removed it because we didn't remember that the logs API uses it. See this commit.

I think it'd be worth considering a way to add it back, even if it's not backwards compatible.

PS: I'm glad that crate was useful for you 🎊

[tannerntannern]

Thanks for the quick response. Regarding exposing the ID, I'm wondering if it would be sufficient to simply make the extension_id field public? I like the idea of the library managing the extension registration for me so I can just read the ID afterwards. I'm not well versed in Rust design patterns though, so I'm not sure if that would be an acceptable solution.

[nmoutschen]

In term of backward compatibility, I think we can still add it back since we didn't publish a new crate version yet. As long as something is on the master branch but not yet publishes on crates.io, we should be flexible. Basically, I see the master branch as an unstable version. 😄

I think as a short term, we could expose the extension ID (maybe it could be useful for other things in the future - e.g. even just for logging purposes), but I'm unsure what the best way to expose it would be.

That said, long term, we should definitively have a high-level library to interact with the Logs API. For the latter, happy to draft an RFC once I'm back from the winter break.

[calavera]

This might need some more work: #394 (comment)

[nmoutschen]

I started an RFC issue to track what the experience would look like: #396

I'd appreciate feedback/ideas on it. 🙂