GET_SESSION_ERROR with Fauna DB

[taylorhlabs]

I have created a brand new DB on Fauna and set it up using details from this thread. For now, I am just testing with the next-auth Email provider. The verification_requests collection in Fauna DB is populating with data when I request the login link, but I'm getting a GET_SESSION_ERROR in terminal when using the login link received via email and the login doesn't work. Note that the session collection in Fauna never gets populated with session data, hence the GET_SESSION_ERROR I suppose. Anyways, has anyone used the Fauna adapter with the Email provider and has it working? I have the Email provider working with Prisma/MySql but can't get it to work with Fauna.

Error details:

GET_SESSION_ERROR [NotFound: instance not found] {
  description: 'Set not found.',
  requestResult: RequestResult {
    method: 'POST',
    path: '',
    query: null,
    requestRaw: '{"get":{"match":{"index":"session_by_token"},"terms":"2394209a952e3c18fa210dc14b79eccda5a6efc3695c27fc41c83a3b16f4985c"}}',
    requestContent: Expr { raw: [Object] },
    responseRaw: '{"errors":[{"position":[],"code":"instance not found","description":"Set not found."}]}',
    responseContent: { errors: [Array] },
    statusCode: 404,
    responseHeaders: {
      connection: 'keep-alive',
      'content-length': '87',
      'content-type': 'application/json;charset=utf-8',
      'x-byte-read-ops': '0',
      'x-byte-write-ops': '0',
      'x-compute-ops': '1',
      'x-faunadb-build': '20.12.01.rc2-577dba9',
      'x-query-bytes-in': '121',
      'x-query-bytes-out': '87',
      'x-query-time': '4',
      'x-read-ops': '0',
      'x-storage-bytes-read': '0',
      'x-storage-bytes-write': '0',
      'x-txn-retries': '0',
      'x-txn-time': '1609441396109324',
      'x-write-ops': '0'
    },
    startTime: 1609441396082,
    endTime: 1609441396143
  }
}

Below is the script I'm using to populate Fauna DB via the Fauna shell.

Create collections:

CreateCollection({name: 'account'});
CreateCollection({name: 'session'});
CreateCollection({name: 'user'});
CreateCollection({name: 'verification_request'});

Then create indexes:

CreateIndex({
    name: 'account_by_provider_account_id',
    source: Collection('account'),
    unique: true,
    terms: [
        { field: ['data', 'providerId'] },
        { field: ['data', 'providerAccountId'] }
    ]
});

CreateIndex({
    name: 'session_by_token',
    source: Collection('session'),
    unique: true,
    terms: [
        { field: ['data', 'sessionToken'] }
    ]
});

CreateIndex({
    name: 'user_by_email',
    source: Collection('user'),
    unique: true,
    terms: [
        { field: ['data', 'email'] }
    ]
});

CreateIndex({
    name: 'verification_request_by_token',
    source: Collection('verification_request'),
    unique: true,
    terms: [
        { field: ['data', 'token'] }
    ]
});

[waptik]

Ok. I think i came across this issue once.
Here's what i was suggested and i did:

1. create a new key but this time set Role to admin
2. go to .env.local comment out the existing key or completely remove it if you want and replace it with the new key
3. try the authentication and see if it work
4. if it works do replace the admin key with server key again and try(if this stage doesn't work, then maintain the previous stage)

[taylorhlabs]

Still getting the same error with Admin role key instead of Server role key. It seems like session data is not being populated into the session collection so not sure exactly where it's breaking...

[Joev-]

Hi @taylorhlabs , I saw you were having trouble in the PR and have tested things out my end. The Email provider is working with FaunaDB, I can send emails from my app and sign in using the magic link provided in the email.

Your setup looks correct. Are you able to manually query the index from the Fauna dashboard? Appreciate you found the typo in the original setup script, I'll update the PR comment in case others come by it until documentation is available.

Can you verify if any data is being populated at all from the Fauna dashboard also? You say it seems like data is not being populated into the collection, but is that actually the case?

[taylorhlabs]

Hey @Joev- thanks for chiming in. I can confirm that data is populating to the verification_request collection in Fauna just by looking at the collection in the dashboard Collections UI. I didn't try manually querying it though.

I just ran a side by side debug with Prisma (working) and Fauna (not working). In the Fauna terminal, after getuserbyemail fires you can see that getsession fires before the user is created and a session is created. In the Prisma example, a user and session are created before getsession.

Do you suspect there is something up with the index or query in Fauna? Can we assume getuserbyemail is returning a matching user in the Fauna example so it doesn't create a user? (The user collection is empty in Fauna though.)

[Joev-]

Thanks for the screenshot, I'm not too sure right now but I can look into it tomorrow for you

[taylorhlabs]

Welp, I continued to do some testing (and adding some console.logs) and it just started working! I dunno if it was switching from the Server key to Admin key as suggested by @waptik but it's currently working now with the Admin key. But the first few tests definitely failed after switching to the Admin key. Wondering if there was some issue on Fauna's side that just needed some time to work itself out? No clue why it just started working. Still, it's weird to see the behavior I included in the screenshot where Fauna just seemed to skip from getuserbyemail to getsession and skip over creating a user and session.

Anyways, Email verification now seems to be working and new users are added to the user collection as expected.

[Joev-]

Glad to hear it is working. The only reason I can think of the difference between the two could be due to an existing session cookie. You can see here that if a non-jwt session token is present during the callback, it attempts to read the session in order to delete it, but this occurs prior to the getUser request, unlike in your example.