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

[renyuneyun]

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

[NSeydoux]

Hi @renyuneyun , thanks for reporting this. I'm wondering if it could be related to #2339. We'll investigate this too.