Hey all, happy new year. I blew the dust off my SS...
# help
m
Hey all, happy new year. I blew the dust off my SST demo app and updated to the latest version of SST (and fixed the auth stuff). However, my (very simple) test is failing suddenly. Looking for anyone who can provide some insight into why
t
it looks like maybe the error is cropped?
m
Here the full output:
Those go warnings are weird too. The stacks run and deploy just fine
Going back to
0.51.1
fixes it. I'll look at the changelogs to see what I missed
@thdxr it starts to happen when updating to
v0.54.0
@thdxr is there anything obvious that I'm missing in upgrading to
0.54.0
here?
t
are these go functions?
It looks like the go build command is failing with those errors
m
that handler is a go function. Everything works as expected pre
0.54.0
t
Can I see the whole test?
t
and it works for sst start and sst deploy?
m
Double checking
I'm 99% certain
sst start
works.
sst deploy
I know is failing as well because my Github Actions have also failed for version >=
0.54.0
t
Got it so there's an issue with how we're building the go code
m
Can confirm -
sst start
works just fine
t
what happens when you invoke the function though
m
let me check
t
We don't build the function right away for sst start until it's used once
m
That's the test API handler
That's it, the users handler isn't building @thdxr
Copy code
f90d2b34-9c74-4f24-a9c6-7f5aade88e2d REQUEST cliffom-sst-bff-demo-apollo-s-ApolloLambdaB6F60C8A-JtgtsktKMccv [src/handlers/apollo/lambda.handler] invoked by API POST /
ed43b770-db83-48c0-8f37-a6e3839edc6a REQUEST cliffom-sst-bff-demo-users-ap-usersHandler1FC87A7B-2BcJJ2X68RMz [src/handlers/api/users] invoked by API GET /users/me
ed43b770-db83-48c0-8f37-a6e3839edc6a ERROR build_failure: The function src/handlers/api/users failed to build

f90d2b34-9c74-4f24-a9c6-7f5aade88e2d RESPONSE {"statusCode":200,"body":"{\"errors\":[{\"message\":\"500: Internal Server Error\",\"locations\":[{\"line\":2,\"column\":3}],\"path\":[\"User... 847 more characters","multiValueHeaders":{"x-powered-by":["Express"],"access-control-allow-origin":["*"],"content-type":["application/json; charset=utf-8"],"content-length":["947"],"etag":["W/\"3b3-44hKDLl6sybPeg4N4zSedxCE0fo\""]},"isBase64Encoded":false}
t
yeah not sure why it's saying User is undefined
let me try something
Copy code
thdxr@challenger /home/thdxr/tmp/sst-bff-demo$ go build src/handlers/api/users/main.go                                                                                                                                                                                                                                                                                                    main
go: downloading [<http://github.com/aws/aws-sdk-go|github.com/aws/aws-sdk-go>](<http://github.com/aws/aws-sdk-go>) v1.41.6
# command-line-arguments
src/handlers/api/users/main.go:52:63: undefined: User
src/handlers/api/users/main.go:53:12: undefined: CreateUser
src/handlers/api/users/main.go:62:91: undefined: User
src/handlers/api/users/main.go:83:10: undefined: User
src/handlers/api/users/main.go:92:13: undefined: GetUserByID
how would you build this function?
That's how sst is trying to build it rn
m
how would you build this function?
I'm not sure what you are asking - the build process was working fine pre
0.54.0
t
I'm a bit rusty in go, if you were just building that handler what go command would you execute?
Right now we're running
go build path/to/handler/main.go
but that's not pciking up the other files in the directory
Should it be
go build path/to/handler/...
?
m
oh, got it. Sorry. Yes, you would need to build all the go files in that directory, in this case something like
go build src/handlers/api/users/*.go
@thdxr Is this enough info for you? Is this something you think can be solved for in the updated build process?
Unless it is resolved, I'm unable to update my repos to
0.54.0
- also this issue will impact any project using Go (unless the Golang handlers are single-file definitions)
t
I'm gonna work on this today - thanks for that
The issue here is if we build everything
*
some people may have multiple handlers in a directory
that get turned into one
m
@thdxr yea, that was my thought given my incredibly simple explanation. It would be hard to enforce something on the users in that regard but ideally (from a code organization POV, especially with Go), you'd have proper directory structures for handlers/packages
t
go build src/handlers/api/users/*.go
isn't supported
Copy code
go build ./src/handlers/api/users/...
works
what I can do is let you point your handler to a directory and if it's a directory I can build with
...
appended
Ah that's what you're doing ok cool
m
@thdxr awesome thank you!
@thdxr Do you have an idea when this will be merged/released?
t
Seeing some test issues that I can't recreate locally, working on this today
m
Can I send you a cup of coffee/tea or something? Really appreciate it!
t
no worries this is my job!
m
Well, I do appreciate it regardless!
t
Hey this is out in 59! But it requires an upgrade to AWS CDK v2
Should be easy for your simple setup
m
@thdxr thank you so much! Will try it out and report ASAP
@thdxr so far so good with the changes (just a single hurdle with a CDK v2 change)
t
woo