Bug report on user invitations and site names

Hi, I don’t need help on this, I got past it, but just wanted to report a bug. I created a site, enabled identity, and then invited myself. I noticed the invite used the temporary name for my site. I changed my site name, which changed the URL, and made the invite not work anymore. That’s fine. I deleted my user - resent the invite - and saw that the subject of the email still had the old site name:

You’ve been invited to join something.netlify.app

The body of the email had the right, new, site name.

1 Like

I actually think I have this issue when adding a custom domain to the site too

Did y’all redeploy after changing your app name? That should be cleared up at the next deploy, after enabling identity and changing the site name. If you don’t see that behavior, please let me know, since that would be a bug rather than the situation which I describe which is working in the way all our features do (requiring a redeploy to activate most setting changes).

1 Like

Hey, so I think my issue was different to OP.
I added a custom domain and in the dashboard the site name changed, however I never actually renamed the “Site Name” as I assumed it had been done automatically :blush:

Probably intentional but just incase:

API ID: c8917f89-5771-44ae-88f0-c1ebda658dbb

I did not redeploy.

OK. Please let me know if it persists once you do!

Did you redeploy, though, Aaron? That setting is one that “starts working” (for receiving site traffic in a browser) without a redeploy, but I suspect the identity settings which are used in those email templates were still “snapshotted in time”)

1 Like

Hey @fool,
I had redeployed since adding the custom domain, which did not change the user invitations.

However, I have since

  1. Manually renamed my site, and redeployed (readme changes) which also did not automatically update my email invitation subject lines.
  2. Manually edited each subject line to be the correct site name, which worked.

Note though that when I edited the subject line manually, the custom invite template was broken until I redeployed, although you stated above that a redeploy is required I thought it worthy to note that it actually broke my template until I redeployed after manually changing the subject line.

Weird! That isn’t the behavior I’d expect, but then, I don’t use that feature at all. Perhaps those subjects are frozen in time forever until you edit them.

Could you describe the nature of the “brokenness” you saw after #2? Seems likely we should get a bug filed but would like to better understand what that looked like to get it filed better :wink:

1 Like

Hey, so I debugged #2 for a little while. There was another issue at hand but will log it here for completeness sake and to see what you think. Please do not feel the need to debug this as it distracts from the original topic and is not causing an issue

The site is a React SPA, I processed a deploy that had an error but succeeded, this resulted in when refreshing the page fully you’d get a 404.
However, since most wouldn’t be refreshing the page, upon registering (with the error in deploy log) the request is sent successfully and the email to register is sent with the Subject line being correct but the template not being provided (It is not in the built files).

So my question would now be concerning, how comes the build succeeded if the zipped build only includes the netlify.toml?
This is the exact deploy that succeeded but results in only a netlify.toml.
Clearly, there is a code error (I tried to use optional chaining in a .js file) but why did it succeed and mess everything else up?

Hey Aaron, super sorry to be so slow to follow up! I think that in the deploy you link, the build failed, based on this message:

11:37:52 AM: ./src/components/Tables/fundSummaryTable/fundSummaryColumns.js 83:12
11:37:52 AM: Module parse failed: Unexpected token (83:12)
11:37:52 AM: File was processed with these loaders:
11:37:52 AM:  * ./node_modules/babel-loader/lib/index.js
11:37:52 AM: You may need an additional loader to handle the result of these loaders.
11:37:52 AM: |           var id = _ref2.id;
11:37:52 AM: |           return id === "".concat(row.id);
11:37:52 AM: >         }))?.["total_profit"] || 0) > 0;
11:37:52 AM: |       },
11:37:52 AM: |       style: {
11:37:52 AM:  @ ./src/components/Tables/fundSummaryTable/FundSummaryTable.jsx 13:0-47 111:13-20
11:37:52 AM:  @ ./src/routes/overview/Overview.jsx
11:37:52 AM:  @ ./src/routes/overview/index.jsx
11:37:52 AM:  @ ./src/routes/index.jsx
11:37:52 AM:  @ ./src/App.jsx
11:37:52 AM:  @ ./src/index.jsx

…that perhaps your build failed, but did not “tell the system” that it failed, by returning a non-zero exit code from the master process which I think at that point was likely npm run build:server. Perhaps some subprocess doesn’t pass the exit code back up to npm, or npm ignores it? webpack --bail is an example of a subprocess that WILL return errors to us, while plain webpack doesn’t necessarily pass the error back up to its caller.