search

sw-tools / checkin-service

Checks the user in to a flight
MIT License
9 stars 3 forks source link

Revert "Remove sleep from sw-generate-headers" #16

Closed swtools0 closed 2 years ago

swtools0 commented 2 years ago

Reverts sw-tools/checkin-service#14

I'm seeing the following error. For some reason, the Lambda puppeteer seems to behave differently from the local version.

ERROR   Invoke Error    {"errorType":"TimeoutError","errorMessage":"Navigation timeout of 30000 ms exceeded","name":"TimeoutError","stack":["TimeoutError: Navigation timeout of 30000 ms exceeded","    at /opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/LifecycleWatcher.js:106:111"]}

Note: it's possible I need to use a confirmation number and first and last name that are actually ready for checkin, but since this new implementation works locally but not in Lambda, I think we may need a new solution to the wait problem.

@aaron-pham correct me if I'm wrong. Reverting to the old wait solution for now, but would like to get rid of it.

aaron-pham commented 2 years ago

I'll have to look into this, but I did end up having some reservations on Lambda that worked. I'll have to confirm this is deployed on my aws.

aaron-pham commented 2 years ago

Hey @swtools0, do you know how to check what version of puppeteer is on my lambda?

I don't see any versions in my HandleScheduleCheckin's node modules. I did confirm that my code in AWS currently does NOT have the sleep in it and I had two successful checkin's since then.

What did you do to get these errors? Send a test payload to HandleScheduledCheckin?

swtools0 commented 2 years ago

Great callout on the Puppeteer version. That could be the discrepancy here. Puppeteer is in the chrome_aws_lambda Lambda Layer. If you go to the local chrome-aws-lambda repo from which you built the chrome_aws_lambda.zip layer and look at its package.json file, you'll find the version you've built. I'm using version 10.1.0.

I tested it by creating a test EventBridge rule and trigger for a flight that was in the middle of its round trip. Creating a test rule and trigger for the same flight successfully retrieved the headers when I reverted the changes of PR #14.

How are you determining what code is deployed?

aaron-pham commented 2 years ago

Hmmm, my puppeteer is the same version. I'm determining what code is deployed by going to HandleScheduledCheckin lambda in the AWS console and hunting for the generate headers code (in the c9 editor), which I do see we're doing the wait for network idle..

Not sure what would be different for why your deployed version had different behavior. I'll sync up my fork, add the optimization back and see if I can recreate the issue you're having.

aaron-pham commented 2 years ago

I see that serverless is throwing errors about the puppeteer version. I wonder if this is related to why my version works and yours didn't?

Serverless: WARNING: Could not determine version of module puppeteer-core
Serverless: Excluding external modules: chrome-aws-lambda@^10.1.0, puppeteer-core
Serverless: Package lock found - Using locked versions
Serverless: Packing external modules: @aws-sdk/client-eventbridge@^3.43.0, http-status@^1.5.0, luxon@^2.1.1, uuid@^8.3.2, got@^11.8.3, @aws-sdk/client-sqs@^3.51.0, promise.any@^2.0.3
Serverless: WARNING: Could not determine version of module puppeteer-core
aaron-pham commented 2 years ago

@swtools0

Okay, so I see I did get the same errors you were getting. I've looked into it more and it's an error when the page loads to slow and never goes idle, so we don't get the signal to continue, and we hit the 30 second time out.

This area of the code is working fine as of now and I don't want to waste anymore time on it so I'll be calling the sleep as "good" for now lol.

I'll start to implement notifications soon.