Vertex IDs not mapped when writing Tuple TO_CSV

GSQL
#1

Problem
When writing query results to csv, I ran into a scenario where the internal vid’s are not mapped to external ids. This happens when the result set is a user defined tuple. For example:

    CREATE QUERY sampleQueryTOCSV(/* Parameters here */) FOR GRAPH MyGraph SYNTAX V2 { 
    /* 
    Constructs triples and writes to local file
    */

    TYPEDEF TUPLE <Vertex src, STRING edg, VERTEX tgt> TRIPLE_RECORD;  
  
    SetAccum<TRIPLE_RECORD> @@triples;
  
    FILE file1 ("/home/tigergraph/data/triples.txt");

    start = {ANY.*};
  
    res = SELECT tgt FROM start:s - ((ANY|ANY>):e1) - ANY:tgt 
          WHERE s != tgt 
          ACCUM @@triples += TRIPLE_RECORD(s, e1.type, tgt);

    PRINT @@triples TO_CSV file1;
    PRINT COUNT(@@triples), @@triples;
    PRINT "Written results to file.";
    }

The fields src and tgt as seen in the triples.txt file are the internal integer ids, while the JSON response (@@triples) contains the external ids.

Expected result
When writing the result set to either csv or json I would expect to resolve the vertex ids to the external ids.

Other observations
Situations where the TO_CSV capability does work as expected (where vertex ids are mapped to external ids), is when a vertex set is written directly, or as part of an accumulator e.g. SetAccum<Vertex> @@v_collection

Is this behaviour expected? Is there a way to push the output through the ID mapper?

#2

This behavior is expected, as the id mapping happens later in the process.

If you want the specific fields available in the TO_CSV, then you can store the vertex id’s on the vertex and retrieve them explicitly.

I’ll check with product to make sure this is still the correct understanding.