Skip to content

fix(docs): examples/extension-internal-flush: don't refer to a standalone layer arn for internal extension #980

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jlizen
Copy link

@jlizen jlizen commented May 2, 2025

📬 Issue #, if available:
n/a

✍️ Description of changes:

Small tweak to the docs for our example on internal extensions. We currently refer to retrieving a layer arn from cargo lambda deploy. This was probably copy-pasted from other examples where we actually are calling cargo lambda deploy with the --extension target.

In this case, we are deploying the function directly, and there is no standalone extension - it is all inside our primary binary.

Tweaking the language to remove a reference to a deployed layer ARN.

If we want to add a guide to invoking the remote function deployment, we could. The other examples don't have that though.

🔏 By submitting this pull request

  • [x ] I confirm that I've ran cargo +nightly fmt.
  • [ x] I confirm that I've ran cargo clippy --fix.
  • [x ] I confirm that I've made a best effort attempt to update all relevant documentation.
  • [x ] I confirm that my contribution is made under the terms of the Apache 2.0 license.

@jlizen
Copy link
Author

jlizen commented May 2, 2025

Actually, this isn't working properly in my local testing. I think the original command was wrong. I'll open a new one later.

@jlizen jlizen closed this May 2, 2025
@jlizen
Copy link
Author

jlizen commented May 2, 2025

Reopening, my issues testing locally seem to be due to a bug in cargo lambda: cargo-lambda/cargo-lambda#848

This was actually called out when this example was first added:
#744 (comment)

The commands work fine as written:

cargo lambda build --release
cargo lambda deploy --release
cargo lambda invoke extension-internal-flush --remote --data-ascii '{"Records":[{"messageId":"MessageID_1","receiptHandle":"MessageReceiptHandle","body":"{\"a\":\"Test\",\"b\":123}"}]}'

which returns:

{"batchItemFailures":[]}

And then AWS logs show the extension running in-process:

EXTENSION	Name: internal-flush	State: Ready	Events: [INVOKE]
START RequestId: a6bd9cf2-79f9-4301-906c-37d70c19fc7f Version: $LATEST
[runtime] received event Data { a: "Test", b: 123 }
[extension] waiting for event to be processed
[extension] flushing logs and telemetry
END RequestId: a6bd9cf2-79f9-4301-906c-37d70c19fc7f
REPORT RequestId: a6bd9cf2-79f9-4301-906c-37d70c19fc7f	Duration: 35.16 ms	Billed Duration: 36 ms	Memory Size: 128 MB	Max Memory Used: 13 MB	

@jlizen jlizen reopened this May 2, 2025
@jlizen jlizen changed the title fix: examples/extension-internal-flush: don't refer to a standalone layer arn for internal extension fix: docs: examples/extension-internal-flush: don't refer to a standalone layer arn for internal extension May 3, 2025
@jlizen
Copy link
Author

jlizen commented May 3, 2025

Have a fix up for the cargo lambda watch bug: cargo-lambda/cargo-lambda#849

This example does successfully run locally with that fix in place.

@jlizen jlizen force-pushed the main branch 2 times, most recently from 959e418 to 900bf88 Compare May 4, 2025 16:19
@jlizen
Copy link
Author

jlizen commented May 4, 2025

I went ahead and added in:

  • local + remote testing information
    • Our other examples don't include testing details, but finding the right payload was kind of annoying and this seems like the kind of example that our users might want to tinker with, so running it is handy.
    • Note that local testing requires my cargo lambda internal extension in your cargo lambda binary, and it doesn't have a new release yet. I could add a note, but I imagine that a release will be cut pretty soon
  • a TODO to always poll the function handler future first before the telemetry extension future (since anyway the extension just waits for the function to finish)
    • I have an open issue in tokio to support biased with try_join!, you could do it with select! today but it would be very verbose. If I implement that feature in tokio, I'll circle back and update the example
    • This might be a little too detailed for this example, it just bugged me since it is clearly inefficient to poll the extension first, ever. Glad to remove the comment though.

@jlizen jlizen changed the title fix: docs: examples/extension-internal-flush: don't refer to a standalone layer arn for internal extension fix(docs): examples/extension-internal-flush: don't refer to a standalone layer arn for internal extension May 4, 2025
@jlizen
Copy link
Author

jlizen commented May 4, 2025

As another side note, I'd like to update the example to show a more realistic per-event flush via an extension using a non-blocking writer, if I implement this feature in tracing-appender:

(that's assuming this change lands: #982)

…lone layer arn for internal extension deploy, add testing information
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