Unexpected behavior for SharedString.findTile when searching at beginning/end of string about fluidframework

[zagriswo]

Yea, we have a workaround we can use for now. Just not ideal :)

[zagriswo]

Updating the title. This repros when searching backward at the beginning of the string too.

it("Repro findTile() issue [backward]", async () => {
    // ARRANGE
    const sharedString = ...; // Get an empty SharedString somewhere

    // ACT
    sharedString.insertMarker(0, ReferenceType.Tile, {
        markerId: "marker",
        referenceTileLabels: ["Eop"],
    });

    // ASSERT
    expect(sharedString.getLength()).toBe(1);

    // There shouldn't be anything before the beginning of the string...
    const foundTile = sharedString.findTile(0 /*startPos*/, "Eop" /*tileLabel*/, true /*preceding*/);
    // ... but for some reason, we're getting the marker at pos 0... 🧨🧨🧨
    expect(foundTile).toBeUndefined();
});

[Abe27342]

Thanks for the bug report! We already have some work internally tracking improving test coverage on findTile and related underlying functionality--more reason to prioritize that. I've filed a bug for this as well (AB#4616 for FF team members)

Do you have any workaround in the meantime (assuming this is blocking you in some way)? Seems like the kind of thing that might have one if you understand what scenarios it repros in.

[jzaffiro]

I'm working on this issue now, and in doing so we've decided to create a new function that searches by doing a depth first walk of the nodes instead of the current search block functions that we have. We're trying to decide whether the search should exclude the search position that's passed into findTile, whether it should be included in the search, or if we should allow the method to be configurable on whether or not the position is included in the search.

Currently, findTile seems to include 0 as a search position, but exclude any other position in the middle of the string. If the new method is fully exclusive, it would prevent any tile at position 0 from being found in a forward search, but it would match the behavior of the forwardExcursion and backwardExcursion functions. If it's inclusive, the problem with searching at the start of the string is fixed, but it could break some expectations from previous findTile usage.

Let me know if you have a preference as to which solution we move forward with, or if you would be ok with whatever our preference is. None of the existing usage of findTile would be broken immediately, as this solution is for a separate method, but let me know what your thoughts are.

[jzaffiro]

Closing since the solution is merged (#16517). findTile itself is now deprecated in favor of searchForMarker, which is called in the same way as findTile and searches for the nearest marker in the direction indicated. searchForMarker includes the start position in the search as well.