Error Undefined: No se pudo descargar el paquete "Volo.Abp.OperationRateLimiting.Domain.10.3.0" #10638

6 Answer(s)

• 

  0

  AI-Bot created 5 months ago

  Support Team ABP Agent

  • Volo.Abp.OperationRateLimiting.Domain is a commercial (Pro) module, and it is not available for every commercial license tier. If your license doesn’t include that module, the ABP private feed returns 403 (Forbidden) for that specific package/version, while other Volo.Abp.* packages may still restore successfully (because they are included in your tier).
  • For v10.3.x, this module specifically requires ABP Team (or higher). So in your case, the restore error is consistent with a license/module entitlement restriction, not a corrupted project or NuGet client problem.

  What to do (pick one):

  1. If you want to use Operation Rate Limiting

     • Upgrade to a license tier that includes it (Team or higher).
     • Then restore again (the 403 should disappear).

  2. If you don’t need Operation Rate Limiting in this POC

     • Remove the dependency chain that brings it in. In your template, it’s commonly pulled indirectly by Account Pro / related pro modules (and possibly by default template wiring).
     • Practical steps:
       • Search in your solution for any package references like:
         • Volo.Abp.OperationRateLimiting.*
       • Remove those package references and/or remove the module dependency from your DependsOn(...) chain in your *.WebModule / *.HttpApiHostModule (where it gets brought in).

  3. If you believe you should have access but still get 403

     • Re-authenticate your ABP credentials/token and try again (sometimes the local token is stale on a new machine/agent):

  abp logout
       abp login
       dotnet nuget locals all --clear
       dotnet restore
  

  Sources:

  • https://abp.io/docs/latest/modules/operation-rate-limiting
  • https://abp.io/pricing
  • https://abp.io/contact

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  anibale created 5 months ago

  Quick update after trying the AI-Bot suggestions on my side:

  • abp logout + abp login → successful re-login as anibale under organization Madrid Digital.
  • dotnet nuget locals all --clear → cache fully cleared.
  • Clean + Rebuild → same 403 on Volo.Abp.OperationRateLimiting.Domain 10.3.0. All other Volo.Abp.* packages restore fine from the same feed with the same credentials.

  So a stale token / corrupt cache is ruled out, and this looks consistent with a license/ACL restriction on that specific package on your feed.

  To move this forward, I'd appreciate confirmation on two concrete points:

  1. Does my current commercial license tier include the Volo.Abp.OperationRateLimiting module?
  2. If it does not, why does the default app template (ABP Studio 2.2.7, v10.3.x) pull it as a dependency? A freshly generated project from abp new -t app should compile out of the box on any tier that is allowed to use that template. If this module is Team+ only, the template should either skip it or abp new should warn at generation time.

  From a customer perspective this looks like a template packaging issue rather than an entitlement problem on my account, since I never opted in to Operation Rate Limiting and the project is unbuildable on first restore.

  Thanks, Aníbal

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  AI-Bot created 5 months ago

  Support Team ABP Agent

  • Your restore behavior (only that package/version returning 403 while the rest restore fine) matches module entitlement restriction on the commercial feed, not a local NuGet/auth/cache issue.
  • Volo.Abp.OperationRateLimiting is a Pro module and it requires ABP Team (or higher) to use/download. This is explicitly stated in ABP’s Operation Rate Limiting documentation, and it also notes that the module is used by Account (Pro) modules and can come pre-installed in the latest startup templates.

  So for your two concrete questions:

  1. Does your current license tier include Volo.Abp.OperationRateLimiting?
     I can’t see your license tier from here, but the rule is definitive: only Team (or higher) includes it. If you’re on a lower tier, you will get 403 exactly like this when restoring Volo.Abp.OperationRateLimiting.Domain (10.3.0 included).

  2. Why does the default app template pull it?
     Because in v10.3 the module is used internally by Account (Pro) modules and is also described as pre-installed in the latest startup templates. If your template selection (e.g., Social Login / OpenIddictAdmin / other Pro account-related features) caused Account Pro packages/modules to be included, they can bring OperationRateLimiting as a dependency—then restore fails on tiers that don’t include it. Practically, this means the generated solution can become “unbuildable out of the box” unless the generator filters Pro-only modules based on license, which appears to be the gap you’re hitting.

  Workarounds you can apply immediately (to make the solution build without upgrading):

  • Remove the Pro dependency that pulls OperationRateLimiting:
    • In your *.csproj files, remove any PackageReference to Volo.Abp.OperationRateLimiting.* (if present).
    • Also check your DependsOn(...) chain in your POC.ApiSports*.Module classes and remove any module dependency related to OperationRateLimiting (directly) and/or the specific Pro module that introduced it (often via Account Pro features).
  • Regenerate the solution without the feature set that brings Account Pro dependencies (e.g., avoid selecting options that require Pro modules), if possible for the POC.

  If you want this treated as a template/generation issue (so ABP Studio/CLI warns or excludes it based on license), please report it through the official channel so the team can reproduce it against your exact template options and license entitlement:

  • https://abp.io/contact

  (Links validated.)

  Sources:

  • https://abp.io/docs/latest/modules/operation-rate-limiting
  • https://abp.io/pricing
  • https://abp.io/contact

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  anibale created 5 months ago

  Thanks for the AI-Bot follow-up. It actually confirms the diagnosis from my side, but it leaves the two questions I asked unanswered, so I'd like to escalate this to a human support engineer within this same ticket rather than opening a new channel.

  What the AI-Bot already acknowledges:

  • The 403 behavior is consistent with module entitlement restriction on the commercial feed, not a local issue.
  • Volo.Abp.OperationRateLimiting is pulled by Account (Pro) modules and is described as pre-installed in the latest startup templates.
  • Quoting the bot directly: "the generated solution can become 'unbuildable out of the box' unless the generator filters Pro-only modules based on license, which appears to be the gap you're hitting."

  That last sentence is the core of the problem. A paying customer running abp new -t app with ABP Studio 2.2.7 should not get a project that fails to restore on first build. Either the template should filter Pro modules according to the license tier, or abp new should warn at generation time.

  What I still need from a human engineer:

  1. License confirmation. Does my current tier (organization Madrid Digital, user anibale) include Volo.Abp.OperationRateLimiting? The AI-Bot explicitly said it cannot see this; only your team can.
  2. Template behavior. If my tier does not include it, this is a template generation bug, not a customer-side workaround issue. I'd like the team to track it as such. Suggesting that I manually strip PackageReference entries and edit DependsOn(...) chains in a freshly generated solution is not an acceptable workaround for a commercial product — it would also leave the project diverging from the official template, with unclear runtime impact.
  3. Path forward. Either confirm the tier upgrade needed (with the exact module name and minimum tier) so it can be evaluated internally, or provide an official fix / regeneration option that produces a buildable solution on my current tier.

  I'd rather not open a parallel report at abp.io/contact as the bot suggested — the information is already here and duplicating it across channels only adds friction. Could a human engineer pick this up?

  Thanks, Aníbal

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 5 months ago

  Support Team Fullstack Developer

  Hi Aníbal,

  Thanks for the detailed report. You're right that this looks like a license/module entitlement issue on our side rather than something for you to work around in the generated project.

  We'll check and adjust the Personal license entitlement for the Volo.Abp.OperationRateLimiting.* packages on our end. I'll get back to you on this thread once it's done.

  Thanks,

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 5 months ago

  Support Team Fullstack Developer

  Hi Aníbal,

  Quick update — we've granted access to the Volo.Abp.OperationRateLimiting.* packages for the Personal license on our side. Could you give it another try?

  dotnet nuget locals all --clear
  dotnet restore
  

  The 403 should be gone now. Let me know if it still fails on your side.

  Thanks,

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel