Greetings, as the ambitiously long title says, i’m not sure what to try next in order to debug this issue. I’ll try to explain more. If you look at this git commit, in the project in question:
The handler seems to conform correctly to the specification outlined here:
As well as return an acceptable payload. The body is an HTML page the browser should render when I visit the invoke URL given to me by AWS + “/datomic”:
Which it doesn’t. It’s possible I should be able to learn something from the response header, but a lot of those keys are foreign to me. “x-amz-apigw-id”. The Get request seems correct.
I looked at my logs (as best i know-how) and I saw no specific errors in my application.
I suspect I’m not correctly including the compiled assets (HTML, js, css) in my project so they can be handled. Some disconnect between my figwheel local setup and how rum works. For instance, I realized that i would need to include the javascript so as a short-term solution included public/main.out and public/main.js so they would be available. That didn’t change anything.
Usually, my next step in troubleshooting would be to setup a running repl to the server and look at the return value of my handler and go from there. But as i understand it, that’s not an option.
If you are using the newer style HTTP one, you have to explicitly configure the lambda integration, you are assigning to a route, to use the version 1.0 payload format.
That’s a common problem, so I’m mentioning it without looking into the details you shared.
What was the response you got?
I’m offered to download something, when I clicked on your API gateway link, but not sure what, because I just tried it on an iOS device.
So I assume the function webserver/lambda in this case is correctly configured to return assets to the browser, but something prior to that step is wrong.
Given I can’t get any meaningful feedback, I’m going to look for an example where people are servering assets (HTML, css) from a more typical source, rather directly from the lambda. I suspect there is something in that pipeline that is off and it wasn’t a good long term solution anyway. Though I am slightly worried that this kind of obscure (at least to me) problem is a trade off with the cloud setup.
I’m not sure about exactly what’s causing your issue, but some here’s some debugging tips I’ve picked up:
The push command should return the on-disk and in-S3 location for the zip file of your deployment, which you can inspect (I did so locally) to see what’s been picked up for deployment. I used this to debug some missing-assets issues when I deployed my first ion.
You can (I believe, I haven’t done this yet) set up an ingress rule for your primary compute group/query group for port 22 to your bastion box, then ssh to the bastion box and from there jump to the compute node. Something like ssh <public-bastion-ip-or-hostname> -l ec2-user -i ~/.ssh/<something with datomic in the name> where you can find the bastion ip in the list of EC2 instances, though I grabbed both from the output of datomic client access <system-name> by reading through it for lines like Connecting to <bastion ip> and Will attempt key... I don’t know if nodes have REPL connections available locally, but you’ll be able to check out what’s on disk at least.
Aside from that, putting in more log lines around the functions in question, or a try/catch Throwable around your main ion function that logs/prints whatever is caught, may prove fruitful.
Also, I opened up the Dev Console and loaded up the broken link, which returns a 404, a curious response body (random alphanumeric ending in an = sign), and some x-amzn-... headers who have values that look like good candidates to put into the CloudWatch logs search, given their likelihood of only showing up for your specific request. x-amzn-trace-id and x-amzn-request-id look particularly promising, depending on the logging the ions do for your particular kind of endpoint.