New solver does not add dictionary literals to EDB, so it always returns "NoAnswer"

[emlaufer]

With the following predicate, the solver returns "NoAnswer"

init_membership(state) = AND(
    DictContains(?state, "test", 0)
)

REQUEST(
    init_membership({"admins": [], "members": [], "test": 0})
 )

I was able to solve this by manually adding the {"admins": [], "members": [], "test": 0} to the edb, but I assume this should be done automatically.

[robknight]

This should be fixed in the latest commit on the no_pod_id_solver branch.

[emlaufer]

Great this now works for me! A similar related issue:

invite(state, invite_pk, private: admin_arr, admin_pk, admin_sk) = AND(
    DictContains(?state, "admins", ?admin_arr)
    ArrayContains(?admin_arr, 0, ?admin_pk)
)

This predicate is successfully solvable, but this is not:

invite(admins, invite_pk, private: admin_pk, admin_sk) = AND(
    ArrayContains(?state["admins"], 0, ?admin_pk)
)

[dgulotta]

I ran into an issue that seems similar: the following is not solvable.

swamp_helper(frog, ids) = AND(
    DictContains(?frog, "ownerPublicKey", ?ids["owner"])
) 

[robknight]

Unfortunately I haven't completed support for the new anchored key system. The "old-style" approach has a "closed world" of known roots, being the PodIds of the input PODs. The new system allows for keys that index into literals, which isn't fully supported yet. I don't imagine that it's a huge change, though.

A similar unsupported feature is the new container update predicates - these also add a level of dynamic container creation and would require a slightly bigger change, whereby constraint handlers suspend rather than reject anchored keys for which there's not (currently) an available binding, as it would become possible for new ones to emerge.