Inconsistent behaviour of `getResourcePolicyAll()` and `getPolicyUrlAll()` for ACP

Search terms you've used

• ACP
• getResourcePolicyAll
• getPolicyUrlAll

Bug description

There are two functions exposed from acp_ess_2, one named getResourcePolicyAll() and the other named getPolicyUrlAll(). Based on their doc, I expect them to identity the same set of policies, though one returning the policy themselves (as a dataset) and the other result the array of URLs/URIs.

However, in my tests, they do not behave this way. In the example below, getPolicyUrlAll() returns policies, while getResourcePolicyAll() returns empty array.

To Reproduce

1. Create a resource with the .acr file as pasted below
2. Call these two functions respectively at the resource

Minimal reproduction

The template says to use a CodeSandBox, however the provided one is empty, and I cannot figure out how to use it easily. Because the issue is straightforward, I'm providing the .acr file.

Assume the resource locates at https://MY-SITE/test/test-acr-1/res1.ttl.
Create the following .acr file for it: https://gist.github.com/renyuneyun/834eb5ee542e06a2cc3ee1a57712ca3f

Expected result

Both return the same set of policies (in different formats)

Actual result

getPolicyUrlAll() returns policies, while getResourcePolicyAll() returns empty array.

Environment

  System:
    OS: Linux 6.6 Arch Linux
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
    Memory: 1.90 GB / 15.40 GB
    Container: Yes
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.6.1 - ~/node_modules/.bin/node
    Yarn: 1.22.21 - /usr/bin/yarn
    npm: 10.4.0 - /usr/bin/npm
  Browsers:
    Chromium: 122.0.6261.57
  npmPackages:
    @comunica/query-sparql: ^2.8.1 => 2.10.0 
    @inrupt/solid-client: ^2.0.0 => 2.0.0 
    @inrupt/solid-client-authn-browser: ^2.0.0 => 2.0.0 
    @inrupt/vocab-common-rdf: ^1.0.5 => 1.0.5 
    @inrupt/vocab-solid: ^1.0.4 => 1.0.4 
    @mdi/font: ^7.1.96 => 7.2.96 
    @renyuneyun/solid-helper: ^0.0.3 => 0.0.3 
    @rushstack/eslint-patch: ^1.1.4 => 1.3.2 
    @tsconfig/node20: ^20.1.0 => 20.1.0 
    @types/n3: ^1.10.4 => 1.16.0 
    @types/node: ^20.4.4 => 20.4.4 
    @vitejs/plugin-vue: ^4.0.0 => 4.2.3 
    @vue/eslint-config-prettier: ^8.0.0 => 8.0.0 
    @vue/eslint-config-typescript: ^11.0.0 => 11.0.3 
    @vue/tsconfig: ^0.4.0 => 0.4.0 
    eslint: ^8.22.0 => 8.45.0 
    eslint-plugin-vue: ^9.3.0 => 9.15.1 
    n3: ^1.16.3 => 1.17.2 
    npm-run-all: ^4.1.5 => 4.1.5 
    path-browserify: ^1.0.1 => 1.0.1 
    pinia: ^2.1.4 => 2.1.4 
    prettier: ^3.0.0 => 3.0.0 
    solid-helper-vue: ^0.1.4 => 0.1.4 
    typescript: ^5.1.6 => 5.1.6 
    vite: ^4.0.0 => 4.4.6 
    vue: ^3.3.4 => 3.3.4 
    vue-tsc: ^1.0.12 => 1.8.6 
    vuetify: ^3.3.9 => 3.3.9 
  npmGlobalPackages:
    @quasar/cli: 2.3.0
    @renyuneyun/solid-helper: 0.0.3
    @renyuneyun/parse-link-header-ts: 1.0.1
    orchestrator-app: 0.1.0
    solid-helper-vue: 0.2.0
    solid-shell: 2.0.8
    vercel: 32.5.5

Additional information

When looking into the repo, it seems this is probably related to the fact that the repo contains several (not exactly same) copies of similar-purpose code, under policy.ts (, control.ts) and policy/.
The function getResourcePolicyAll() calls policy#getPolicyUrlAll() (i.e. control#getPolicyUrlAll()) while acp_ess_2.getPolicyUrlAll() is reexported from src/acp/policy/getPolicyUrlAll.ts#getPolicyUrlAll().
It feels to me like an incomplete transition from one (code) organization to another.

This may be related to #1641

Start by comparing src/acp/policy.ts, control.ts, and src/acp/policy/getPolicyUrlAll.ts, following the acp_ess_2 exports and the getResourcePolicyAll() call path. Reproduce the discrepancy with the .acr file from the linked gist and compare both functions' results. Done means the two functions identify the same policies in the reported case, using their respective return formats.