Codestin Search App

nopcoder · 2026-02-24T16:08:16Z

Update the link verification time from 6h to 24h.
Same for GC client default set to 24h.

arielshaqed · 2026-02-24T20:11:13Z

I understand why this change. But ideally we would recall why we had this in the first place, and what the cost of removing it will be.
IIUC once we remove this any older link can just be GCed away. We should document that.

N-o-Z · 2026-02-24T20:32:30Z

I understand why this change. But ideally we would recall why we had this in the first place, and what the cost of removing it will be. IIUC once we remove this any older link can just be GCed away. We should document that.

The implications are - physical addresses that are uploaded and not linked within the 6 hour grace period are in danger of being removed by the GC process.

@nopcoder I have a proposal for mitigation - since a big part of the risk here is to link a non-existing object, can we add a check that there's actually an object at the physical location before linking it?
This could substantially reduce the risk here

nopcoder · 2026-02-24T23:32:13Z

@N-o-Z I think that checking the object during link will prevent the use of the API while working with minimal permission - as far as I know the user can link data while the client have the permissions to upload the data while lakeFS doesn't have permission to read.
And there is also the fact that it will make the API much slower if we perform a call to the object store at this point.

@arielshaqed document the openapi spec like we did for copy object?

N-o-Z · 2026-02-25T02:48:08Z

@N-o-Z I think that checking the object during link will prevent the use of the API while working with minimal permission - as far as I know the user can link data while the client have the permissions to upload the data while lakeFS doesn't have permission to read. And there is also the fact that it will make the API much slower if we perform a call to the object store at this point.

@arielshaqed document the openapi spec like we did for copy object?

In this case I think we need to discuss this change further

github-actions · 2026-02-26T17:01:28Z

📚 Documentation preview at https://pr-10180.docs-lakefs-preview.io/

(Updated: 2/27/2026, 8:06:01 AM - Commit: 6383a03)

nopcoder · 2026-02-26T17:03:08Z

@N-o-Z made it configurable and update the description with the findings.

N-o-Z

Thanks!

Can we add this to the lakeFS config please (maybe in capabilities)?
This solution is not complete until we use this configuration in the GC client

itaiad200 · 2026-02-26T17:16:08Z

Can you add the reasoning for making it configurable? I thought we wanted to remove it completely

nopcoder · 2026-02-27T08:12:05Z

Can we add this to the lakeFS config please (maybe in capabilities)? This solution is not complete until we use this configuration in the GC client

Updated - thanks!

nopcoder · 2026-02-27T08:12:24Z

Can you add the reasoning for making it configurable? I thought we wanted to remove it completely

Added it into the notes of the PR.

itaiad200

I think we should reduce complexity, not additional guardrails, configuration and more functionality that is not really needed. I believe the users shouldn't be aware of that, should be allowed to configure it, and we should not validate timestamps while linking.

nopcoder · 2026-02-28T07:23:59Z

I think we should reduce complexity, not additional guardrails, configuration and more functionality that is not really needed. I believe the users shouldn't be aware of that, should be allowed to configure it, and we should not validate timestamps while linking.

The current guardrail prevents the possibility of long-running uploads being deleted. Unlike other operations, where you can run GC within a specific timeframe, uploads of large data are not easy to coordinate.

N-o-Z

Thanks,
I'm only blocking because I think disabling the grace time altogether will be a major issue.
If it is already configurable - let the user configure it to as long as they wish.
Disabling it completely without understanding the GC implications could be disastrous.
Also, think about what will be the expected behavior for GC when the grace is 0?

N-o-Z · 2026-03-01T18:08:19Z

pkg/api/controller.go


 	writeResponse(w, r, http.StatusOK, apigen.GarbageCollectionConfig{
-		GracePeriod: swag.Int(int(catalog.LinkAddressTime.Seconds())),
+		GracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),


Suggested change

GracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),

GarbageCollectionGracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),

Or:

Suggested change

GracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),

LinkAddressGracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),

N-o-Z · 2026-03-01T18:11:11Z

docs/src/reference/configuration.md

 * `graveler.ensure_readable_root_namespace` `(bool: true)` - When creating a new repository use this to verify that lakeFS has access to the root of the underlying storage namespace. Set `false` only if lakeFS should not have access (i.e pre-sign mode only).
 * `graveler.max_batch_delay` `(duration : 3ms)` - Controls the server batching period for references store operations.
 * `graveler.background.rate_limit` `(int : 0)` - Requests per seconds limit on background work performed (default: 0 - unlimited), like deleting committed staging tokens.
+* `graveler.link_address_expiration` `(duration : "6h")` - How long a pre-signed staging upload address remains valid. Set to `0` to disable the expiration check.


If we decided to make this configurable, I suggest having a minimal grace that makes sense (let's say 6 hours) and if a user needs more than that they can configure this to be as big as they want.
Disabling the grace altogether still creates an issue with GC

itaiad200 · 2026-03-02T12:45:20Z

I think we should reduce complexity, not additional guardrails, configuration and more functionality that is not really needed. I believe the users shouldn't be aware of that, should be allowed to configure it, and we should not validate timestamps while linking.

The current guardrail prevents the possibility of long-running uploads being deleted. Unlike other operations, where you can run GC within a specific timeframe, uploads of large data are not easy to coordinate.

So let's extend the grace period from 6 hours to 24 hours and be done with it. I don't see the value of making this configurable.

nopcoder · 2026-03-02T15:51:34Z

@itaiad200 update the code to set time verification limit to 24h.

N-o-Z · 2026-03-02T15:58:48Z

I think we should reduce complexity, not additional guardrails, configuration and more functionality that is not really needed. I believe the users shouldn't be aware of that, should be allowed to configure it, and we should not validate timestamps while linking.

The current guardrail prevents the possibility of long-running uploads being deleted. Unlike other operations, where you can run GC within a specific timeframe, uploads of large data are not easy to coordinate.

So let's extend the grace period from 6 hours to 24 hours and be done with it. I don't see the value of making this configurable.

I just want to clarify the implications of this change.
This means that 24hrs is going to be the smallest resolution for the GC process.
This change must be coupled with modification of the GC client

N-o-Z · 2026-03-02T15:59:05Z

I think we should reduce complexity, not additional guardrails, configuration and more functionality that is not really needed. I believe the users shouldn't be aware of that, should be allowed to configure it, and we should not validate timestamps while linking.

The current guardrail prevents the possibility of long-running uploads being deleted. Unlike other operations, where you can run GC within a specific timeframe, uploads of large data are not easy to coordinate.

So let's extend the grace period from 6 hours to 24 hours and be done with it. I don't see the value of making this configurable.

I just want to clarify the implications of this change. This means that 24hrs is going to be the smallest resolution for the GC process and the retention policy. This change must be coupled with modification of the GC client

Co-authored-by: Amp <[email protected]> Amp-Thread-ID: https://ampcode.com/threads/T-019caef6-8f86-755c-926d-e3722e913822

nopcoder · 2026-03-02T16:27:52Z

This change must be coupled with modification of the GC client

Thanks @N-o-Z updated the client code too.

itaiad200

Thanks.
I think this change is reasonable. 24 hours to complete a single file write to the storage and updating it in lakeFS should be more than enough. The only downside for extending the grace period is that objects are deleted 18 hours later - I think it's worth the reduced complexity.

I still don't understand why we need to verify long running multipart upload. Are we concerned about a multipart upload taking more than 24 hours, completed in the object store (uncompleted mpu are not gc'd) so it could be seen by the GC, but not registered in lakeFS? I find this race condition impossible, it could only occur if someone deliberately chooses not to complete mpus, and we can document the implications when GC is running.
We can do this in a separate PR though.

Amp-Thread-ID: https://ampcode.com/threads/T-019cafe9-4108-73b8-94d3-3e946ba8f2d6 Co-authored-by: Amp <[email protected]>

nopcoder self-assigned this Feb 24, 2026

github-actions bot added area/cataloger Improvements or additions to the cataloger area/testing Improvements or additions to tests labels Feb 24, 2026

nopcoder added include-changelog PR description should be included in next release changelog mostly-ai labels Feb 24, 2026

nopcoder mentioned this pull request Feb 24, 2026

Remove LinkAddressTime link address expiration verification #10182

Closed

nopcoder requested a review from N-o-Z February 24, 2026 19:56

nopcoder marked this pull request as ready for review February 24, 2026 19:56

talSofer mentioned this pull request Feb 25, 2026

How to configure LinkAddressTime expiration with API (e.g. 24h) #10174

Closed

nopcoder changed the title ~~Remove link address expiration check from VerifyLinkAddress~~ Make link address expiration configurable Feb 26, 2026

github-actions bot added docs Improvements or additions to documentation and removed area/testing Improvements or additions to tests labels Feb 26, 2026

N-o-Z requested changes Feb 26, 2026

View reviewed changes

nopcoder force-pushed the remove/link-address-expiration branch from 81db273 to 6383a03 Compare February 27, 2026 08:05

nopcoder requested a review from N-o-Z February 27, 2026 08:12

itaiad200 requested changes Feb 27, 2026

View reviewed changes

nopcoder requested a review from itaiad200 March 1, 2026 14:57

N-o-Z requested changes Mar 1, 2026

View reviewed changes

nopcoder force-pushed the remove/link-address-expiration branch from 6383a03 to c50eb05 Compare March 2, 2026 15:47

github-actions bot removed the docs Improvements or additions to documentation label Mar 2, 2026

nopcoder changed the title ~~Make link address expiration configurable~~ Verify link address expiration set to 24h Mar 2, 2026

Set LinkAddressTime to 24h

5d5de83

Co-authored-by: Amp <[email protected]> Amp-Thread-ID: https://ampcode.com/threads/T-019caef6-8f86-755c-926d-e3722e913822

nopcoder force-pushed the remove/link-address-expiration branch from c50eb05 to 5d5de83 Compare March 2, 2026 16:27

github-actions bot added the area/client/spark label Mar 2, 2026

nopcoder requested a review from N-o-Z March 2, 2026 16:28

itaiad200 approved these changes Mar 2, 2026

View reviewed changes

Update test to expect 24h LinkAddressTime instead of 6h

b79f1f4

Amp-Thread-ID: https://ampcode.com/threads/T-019cafe9-4108-73b8-94d3-3e946ba8f2d6 Co-authored-by: Amp <[email protected]>

github-actions bot added the area/testing Improvements or additions to tests label Mar 2, 2026

	GracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),
	GarbageCollectionGracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),

	GracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),
	LinkAddressGracePeriod: swag.Int(int(c.Catalog.LinkAddressExpiration.Seconds())),

Conversation

nopcoder commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arielshaqed commented Feb 24, 2026

Uh oh!

N-o-Z commented Feb 24, 2026

Uh oh!

nopcoder commented Feb 24, 2026

Uh oh!

N-o-Z commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nopcoder commented Feb 26, 2026

Uh oh!

N-o-Z left a comment

Choose a reason for hiding this comment

Uh oh!

itaiad200 commented Feb 26, 2026

Uh oh!

nopcoder commented Feb 27, 2026

Uh oh!

nopcoder commented Feb 27, 2026

Uh oh!

itaiad200 left a comment

Choose a reason for hiding this comment

Uh oh!

nopcoder commented Feb 28, 2026

Uh oh!

N-o-Z left a comment

Choose a reason for hiding this comment

Uh oh!

N-o-Z Mar 1, 2026

Choose a reason for hiding this comment

Uh oh!

N-o-Z Mar 1, 2026

Choose a reason for hiding this comment

Uh oh!

itaiad200 commented Mar 2, 2026

Uh oh!

nopcoder commented Mar 2, 2026

Uh oh!

N-o-Z commented Mar 2, 2026

Uh oh!

N-o-Z commented Mar 2, 2026

Uh oh!

nopcoder commented Mar 2, 2026

Uh oh!

itaiad200 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nopcoder commented Feb 24, 2026 •

edited

Loading

github-actions bot commented Feb 26, 2026 •

edited

Loading