age: Crash on Edge MERGE after Edge MATCH
Describe the bug Usually, the MERGE operation works. But when a merge operation follows a MATCH clause that includes an edge, the server terminates.
How are you accessing AGE (Command line, driver, etc.)?
- Command line
- Golang driver
What data setup do we need to do?
...
SELECT create_graph('test');
SELECT * from cypher('test', $$ CREATE (a {x:1})-[:foo]->(b {x:2}),(c {x:3}) $$) as (v0 agtype);
...
What is the necessary configuration info needed?
- N/A
What is the command that caused the error?
SELECT * from cypher('test', $$ MATCH ()-[a:foo]->(), (b {x:2}),(c {x:3}) MERGE (b)-[d:bar]->(c) RETURN d $$) as (v0 agtype);
Error:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Expected behavior The relationship should be created if it doesn’t exist.
Environment (please complete the following information):
- Version: 1.1.0, commit ed44f91cb2607605ec2e225248e9ca46e146c215; also fails in earlier releases.
Additional context N/A
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 35 (24 by maintainers)
@jrgemignani So, with respect to the issue_369 test script present in patch, if i change:
()-[a:foo]->()to either:(x)-[a:foo]->()or()-[a:foo]->(y)The extension still segfaults, if instead i use:
(x)-[a:foo]->(y)works and outputs like with the patch applied.Obviously the null check is valid by itself but the question would now be: are anonymous nodes allowed or should they be blocked?
If they are allowed than probably they should have an auto generated name attached. If they are not then there should be a syntax error triggered before evaluation.
Please advise.
Of course, i was already working on it 😄
Please don’t take offense to any bolding, I did it strictly for emphasis. This is a compilation from many sources, not just from here.
At the risk of repeating myself, and for future contributors and contributions -
Bounties - and their websites - have NO connection to Apache AGE. Meaning, we neither condone, prohibit, support monetarily or otherwise, bounties, in any way. This may change in the future. So, use/do them at your own risk.
If someone wants to set a bounty, Apache AGE has zero obligation to support or approve any PR derived from it. If someone hopes that their PR will get approved, they need to, at the very least, follow our standards. Remember, Apache AGE did not ask for any bounties, nor put them up, nor fund them.
Here is a rough guide of minimum expectations for any PR -
Please understand, we will not always be prompt in responding to these requests. Apache AGE PMCs and committers have a lot of work to do. However, we will try our best.
Hopefully, this will be helpful going forward.
john
Sorry but i don’t seem to be able to find any comment or review on the PR, could you check? thanks.
EDIT: looking at the page you linked i think i’ve found the style issue you referred to (the brackets rule) and pushed the fix
No offense taken on my part. As far as I know there’s no requirement that a PR be merged in order for me to fulfill the obligation I create for myself when I pledge to a bounty. It may, however, require closing - at least temporarily - an issue before the corresponding PR is merged. There’s no particular urgency for me to use code from the main branch, however convenient I imagine it being there to the community at large.
For what it’s worth, I’ve checked out the PR locally and run some basic tests; seems promising so far. I’ll stress test more soon, as I need to figure out whether some bugs I’m seeing in behavior related to this are from my own code or AGE 😅
I see; thanks for the clarification.
The incentive is already created/escrow’d at the BountySource link(s) posted earlier…was only hoping to highlight that, not expecting anyone else to chip in. Oh well.
@TropicalPenguin MERGE & SET have generally been problematic to implement, especially when used in conjunction with other commands. There are a lot of reasons why this is the case.
As both are update commands, they are generally tricky to implement properly - managing transaction ids, command ids, etc. Additionally, both commands have to integrate correctly into the transaction system which works differently depending on the scope of the transaction.
And, we have to find all of the different ways a developer, you, will put these pieces together. So, thank you for your input!
We will need to look into what is causing an issue here.