https://serverless-stack.com/ logo
Join Slack
Powered by
I'm a little hesitant to put this out there as I n...
# sst
r
I'm a little hesitant to put this out there as I need to do more digging but I wanted to mention it in case there's something inherently wrong with what I'm trying to do. I have an SST application that’s initially deployed via Seed. I thought by running 
sst start
locally and specifying the same stage name that's in Seed it should allow me to ‘take over’ that application and route the API calls to my local code. Then, when I'm done, I could kick off the deploy in Seed to remove the debug stack. However, after doing this, all requests immediately fail when running from the Seed deployed version with HTTP 500. I don't think it's even getting as far as hitting the integrated lambdas. If I then run 
sst start
for that stage locally it works again. I've also noticed that I have multiple lambdas by the same name in the account now, I'm wondering if this approach has led to things getting duplicated - haven't proven that yet, that's a job for tomorrow. As I say, I need to do some more investigation in the morning but wanted to mention it in case there's something inherently wrong with what I'm trying to do.
t
Hm that should work. Can you check in cfn ui if there's more stacks than you expect
r
Just checked and there's only the two stacks - one app, one debug stack related.
I'm tempted to delete the lot and start from scratch to see if I can reproduce.
So, interestingly, deleting the app stack via CFN in console has removed all the functions, even those that appeared to be duplicated
Looking at the build logs in Seed I can see an error occurring
Copy code
TypeError: Cannot read property 'length' of undefined
    at /tmp/seed/source/stacks/index.ts:82:19
    at /tmp/seed/source/node_modules/@serverless-stack/resources/src/Stack.ts:31:35
    at Array.map (<anonymous>)
    at new Stack (/tmp/seed/source/node_modules/@serverless-stack/resources/src/Stack.ts:30:59)
    at new OmwOfscBeStack (/tmp/seed/source/stacks/OmwOfscBeStack.ts:29:5)
I'm using the callback form of setDefaultFunctionProps and the SST code that's erroring is related to that:
Copy code
this.defaultFunctionProps = root.defaultFunctionProps.map((dfp) =>
      typeof dfp === "function" ? dfp(this) : dfp
    );
i.e. I'm doing
Copy code
app.setDefaultFunctionProps((stack) => {
  // some checks that require VPN set up go first 
  // but I'm currently bypassing that for simplicity
  // so literally just returning
  return {
    runtime: 'nodejs14.x',
  }
}
I can confirm that removing the callback and using 
app.setDefaultFunctionProps(props);
makes that error go away
So, going to back to the problem I reported last night. I'm now doubtful about whether it ever worked when deployed. i.e. I have a strange situation now where the app will only work if run via 
sst start
I lazily add some optional functions and routes to the Api construct. The problem seems to be that when running locally that when I assign the name of the table to an env var like this it works:
Copy code
DYNAMO_DB_OMW_TABLE_NAME: omwTable.tableName,
However, when I run it normally without the debug stack I get an error saying that the table name is not specified. However, the truly bizarre thing is that, if I look at the console, the value for DYNAMO_DB_OMW_TABLE_NAME is set. The other odd thing that's going on is that epsagon isn't tracing. Which implies that the env var for the Epsagon token is also missing. However, that also shows in the console. Running out of ideas!
Killing the debug session and running the Seed build now fails due to the existence of a DDB table that was created by this stack 😭
It's actually complaining
Copy code
Error: There is already a Construct with name 'cust-sat-table' in OmwOfscBeStack [eon-test-omw-ofsc-be-OmwOfscBeStack-eon-test]
However, it's defined only once
t
What version of SST are you on
r
The latest
0.44.0
Running sst build locally runs without error
t
So this is a seed specific issue?
r
I honestly don't know
I haven't yet tried running 
sst deploy
from my own machine. That'd help to pinpoint if this is down to Seed
No, same problem if I deploy from my machine
t
This is very strange, it's like the stack is being initialized twice
r
Seems like there's a few things going on here. Is it possible that the result of the TypeScript compilation/esbuild bundling could be different when running locally vs when deployed? We are using some static classes and inheritance and it seems to be that a subclass method is not properly overriding the super class
That only seems to be the case when deployed though, running locally it works fine
t
does 
sst build
work?
r
Yep
t
can you share the .build/cdk.out folder
I guess I don't need all of it, just the json files
r
Sure, will DM
I've just had it working deployed from my machine after changing references to this vs class name when referencing the static classes. I.e. always use this - it should have been like that anyway but it still seem strange that it behaved differently. I'm now deploying via Seed to see if it continues to work
t
Wait you're doing 
this.myStaticFunction()
isn't that impossible?
r
Yes, from within that class
t
I thought static methods had to be called with 
ClassName.staticFunction()
r
No you can use this, works well when you have a hierarchy of classes with static methods
We have a base class (DynDb) that has a load of DDB methods, a reference to the DDb client and an initialisation method Then we have sub classes that provide their own getTableName() methods and can add additional functionality. So, in the base class, it needs to use this.getTableName() rather than DynDb.getTableName() so that the subclass method is used to return the table on which to perform the operation
The problem I found was that there were some references to DynDb.someMethod() in the base class which should have been this.someMethod()
I can only assume there must be an esbuild peculiarity
I've no idea what was going on with the existing table thing in the stack, or the multiple methods thing but it's not happening now
t
I was thinking about it being an esbuild thing as well
That's bizarre
r
Yeah, very.
Open in Slack
PreviousNext
Powered by