Skip to content

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

@renyuneyun

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions