Datetime returns object (year, month, day etc) instead of string

[MarianAlexandruAlecu]

Datetime type is returning an object instead of a string

scalar Point
scalar DateTime
scalar PointInput

type Mutation {
  createPosts(input: PostCreateInput!): Post!
    @cypher(
      statement: """
      MATCH (user:User { id: $auth.jwt.sub })
      CREATE (post:Post)-[:HAS_USER]->(user)
      SET
        post = $input,
        post.datetime = datetime(),
        post.id = randomUUID()
      RETURN post
      """
    )
}

type Post {
  id: ID! @id
  title: String!
  description: String!
  datetime: DateTime @readonly
  user: User @readonly @relationship(type: "HAS_USER", direction: OUT)
}

This is how datetime field looks in Neo4J Browser: "2021-06-27T15:34:15.146000000Z"

If I comment scalar DateTime while node is running, it will start to return a string (sometimes)

I would expect to simply return datetime: 2021-06-27T15:34:15.146000000Z so that I can easily parse this in frontend. Maybe I'm missing something obvious in my setup? 🤔

• OS: macOS 11.4 M1
• Version: @neo4j/graphql@1.0.2 & 1.0.3
• Node.js version: v14.17.0

[darrellwarde]

Assuming that the type definitions you have provided are what you're using for your application, you need to remove all of those scalars - they are all automatically generated and included in your schema as soon as you use them anywhere, so you don't need to include them yourself. Point and PointInput aren't even scalars, but object and input types respectively, so this would massively break your schema. Can you sort that out, and then we'll see where we need to go from there?

[darrellwarde]

@MarianAlexandruAlecu, any update on this based on the information above? Will assume fixed and will close in the next few days if no further activity.

[MarianAlexandruAlecu]

@darrellwarde I found the issue. Here is the full code so you can reproduce it.

// index.ts
import fs from "fs";
import path from "path";
import { Neo4jGraphQL } from "@neo4j/graphql";
import { ApolloServer } from "apollo-server";
import neo4jDriver from "neo4j-driver";

// docker run -p8474:7474 -p8687:7687 -e NEO4J_AUTH=neo4j/dev neo4j/neo4j-arm64-experimental:4.3.0-arm64

const driver = neo4jDriver.driver(
  "bolt://localhost:8687",
  neo4jDriver.auth.basic("neo4j", "dev")
);

const neoSchema = new Neo4jGraphQL({
  typeDefs: fs
    .readFileSync(path.join(__dirname, "schema.graphql"))
    .toString("utf-8"),
  driver,
  resolvers: {
    // This is breaking DateTime
    Mutation: {
      login: (_root) => {
        return { token: "token" };
      },
    },
  },
});

const server = new ApolloServer({
  schema: neoSchema.schema,
  introspection: true,
  playground: true,
  uploads: false,
});

server.listen({ host: "localhost", port: "3001", path: "/graphql" }, () => {
  console.log(`🚀 GraphQL server ready at http://localhost:3001/graphql`);
});

# schema.graphql
type Mutation {
  login: String
  createPost(input: PostCreateInput!): Post!
    @cypher(
      statement: """
      CREATE (post:Post)
      SET
        post = $input,
        post.datetime = datetime(),
        post.id = randomUUID()
      RETURN post
      """
    )
}

type Post {
  id: ID! @id
  title: String!
  datetime: DateTime @readonly @timestamp(operations: [CREATE])
}

# package.json
{
  "dependencies": {
    "@neo4j/graphql": "^1.0.3",
    "apollo-server": "^2.25.2",
    "graphql": "^15.5.1",
    "neo4j-driver": "^4.3.1",
    "ts-node": "^10.0.0",
    "tslib": "^2.3.0",
    "typescript": "^4.3.5"
  },
  "scripts": {
    "start": "ts-node index.ts"
  }
}

If I remove resolvers, DateTime is returned as String. With resolvers it returns an object like in the first post.

My guess is that resolvers are replacing some default ones for DateTime? 🤔

Side note: example in documentation is broken. @timestamp does not work with DateTime at all for autogenerated mutations.

datetime: DateTime @readonly @timestamp(operations: [CREATE])

[darrellwarde]

Hey @MarianAlexandruAlecu, thanks for the update here, hopefully we can reproduce using your example!

Side note: example in documentation is broken. @timestamp does not work with DateTime at all for autogenerated mutations.

datetime: DateTime @readonly @timestamp(operations: [CREATE])

Regarding your side note, you are getting this error because it appears (based on the docker run command in your example code) you are not running the Neo4j Docker container with APOC installed. Please follow the steps at https://neo4j.com/labs/apoc/4.0/installation/#docker and update here if that fixes it for you? And could you also try running your example again after you've done this, as even this could be the cause of the problem!

[MarianAlexandruAlecu]

@darrellwarde Good catch! Putting apoc back fixed my error with @timestamp. The initial error it's still there: DateTime is returned as object when resolvers.Mutation exists

[darrellwarde]

@darrellwarde Good catch! Putting apoc back fixed my error with @timestamp. The initial error it's still there: DateTime is returned as object when resolvers.Mutation exists

Cool, at least that narrows down the problem, we'll take a look at the example you posted above. 🙂

[MarianAlexandruAlecu]

Hey @darrellwarde , were you able to reproduce the bug?

[darrellwarde]

Hey @darrellwarde , were you able to reproduce the bug?

I am indeed, might try to figure out what's causing this now! 🙂

[darrellwarde]

Found the problem, will implement a fix now. 🙂

[darrellwarde]

This should now be fixed by #297! 🤞 Our apologies for the delay in finding this one, it was a difficult bug to track down but then very obvious once we've found it! We're going to get it merged and released ASAP.

[MarianAlexandruAlecu]

Thanks a lot @darrellwarde !

[MarianAlexandruAlecu]

It was not easy for me to find exactly what is causing the issue. As you can see, the cause it's not very obvious. Good thing we found and fixed the issue. Good job! 🤝

Btw, @darrellwarde is version V2.0.0 having the same issue? Is 2.0.0 re-using code from 1.0.0? I'm thinking of migrating, but I would not want to bring back this bug

[darrellwarde]

It was not easy for me to find exactly what is causing the issue. As you can see, the cause it's not very obvious. Good thing we found and fixed the issue. Good job! 🤝

Btw, @darrellwarde is version V2.0.0 having the same issue? Is 2.0.0 re-using code from 1.0.0? I'm thinking of migrating, but I would not want to bring back this bug

Hey @MarianAlexandruAlecu, this fix has been merged into the 2.0.0 branch but not released yet. We'll be doing another 2.0.0 alpha (maybe even beta, it's pretty feature-complete) release tomorrow which will contain this fix. 🙂