Vertex not created in the DB - bug?

Hello all.
Today, long-time running and tested queries fail in creating a new vertex of a specific vertex type.
The queries end running OK, as if everything works, including the return value, but a vertex of type “Helper” is not actually committed to the DB.

Other types are created as usual, including within one of these two queries (that creates more than just one vertex type) - only the “Helper” vertex is not created.

I’m saying two queries, as I have two queries tasked with creating a “Helper” type vertex, therefore I could confirm it is not any query-specific issue.

I can re-run the queries over and over again - it always behaves as if there is no such vertex in the DB (otherwise it would raise an error) - it is just silently not committing the vertex in the DB.

Exploring the graph I can see previously created “Helper” vertices - they are still there.
I cannot think of anything other than some bug that ate the wires this morning.

This is all experienced on the Graph Studio with tgcloud 3.4.0 on AWS - running the queries and inspecting the graph (with “Explore Graph”).

Here is the code of one of these two queries:

  /* Create a Helper and "IsA" edge from keyPerson, update keyPerson role. */ 
  
  EXCEPTION helperExists (40001);
  
  STRING keyHelper;
  DATETIME regDate;
  
  regDate = NOW();
  keyHelper = "H" + keyPerson.id; 
  
  //Check if Helper exists
  start = {Helper.*};
  vHelper = SELECT s FROM start:s WHERE s.id == keyHelper;
  IF vHelper.size() > 0 THEN
      RAISE helperExists ("Helper already exists for this person");
  END;
  
  
  INSERT INTO Helper (PRIMARY_ID, status, totalInvitations, totalReplyYes, totalReplyNo, totalReplyLater, totalHelpMinutes, helperDate
  ) VALUES (
    keyHelper, 1, 0, 0, 0, 0, 0, regDate
  );
  INSERT INTO IsA (FROM, TO, createTime) VALUES (
  keyPerson Person,
  keyHelper Helper,
  regDate
  );
  
  keyPerson.roleCode = 3;
  
  PRINT keyHelper; 
}

The “Helper” vertex is not committed.
Every time I run this query I get the keyHelper printed back - never the raised “Helper already exists for this person” error.

How can we check this to see what was broken today?
Thanks!

Hi Mor,

Can I assume that you are using the same the specific helper (ID) again and again for testing purposes and that the Helper vertex get deleted from time to time?
The reason I am asking this is that I think have have seen the same behaviour when a vertex was deleted via REST API using the permanent flag. Is this something that you possibly did?

Hi Szilard.
Yes, of course, I’m running the query again and again with the exact same ID.
I don’t know if it gets inserted and immediately deleted, or if it never gets to be written at all.
I can click the “Run Query” button every second and it will always run through OK, only I never witnessed the vertex in the DB at all.
This is done only using the Graph Studio interface while no other clients sending any requests whatsoever.
So, no permanent flag, no RESP API queries, clean environment.
Thanks!

Hi Mor,

It might indeed be a bug. This bug has been fixed in 3.5.1. Could you try to create a new 3.5.3 instance on TigerGraph Cloud and check your code?

Szilard

Thanks, Szilard.
Indeed, I upgraded to 3.5.3 and it is now working as expected.

@Szilard_Barany even we have been facing the same issue since version 3.5.1. When checked with TG support team they asked us to upgrade…we moved to 3.5.2…but could see the issue there as well…then they asked to move to version 3.5.3…we did that as well…but unfortunately after using 3.5.3 for a short span…the issue surfaced again in 3.5.3. It seems there is some disconnect between GPE and GSE whic is leading to this issue. If running check delete vertex end point…we do see the vertex being created is already deleted. Ticket is still in progress…lets us see if TG support team finds the root cause this time.

Thank you for this important update!
It also worked for me on 3.4.0 until it suddenly stopped working.
This is such a critical issue, I can’t understand how all TG employees are not up on their feet 24/7 just to secure this.
How can we comfortably move into production with this lurking in the horizon?

Thanks for the feedback, @kapilsaini, I was not aware of the recurrence of the issue. I will check with them engineering team. Can you let me know your ticket number?