Resource check on event #122

perk11 · 2025-12-28T00:52:32Z

No description provided.

Copilot

Pull request overview

This PR implements event-driven resource checking to prevent the use of outdated resource check results. Instead of relying solely on periodic timer-based checks, the system now triggers resource availability checks immediately when services connect or disconnect.

Key Changes:

Replaced polling-based resource waiting with an event-driven channel-based system
Added immediate resource check triggering on service lifecycle events (connection/disconnection)
Upgraded Go version from 1.22 to 1.23 to support new language features (iter.Seq)

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
monitor_resources_test.go	Updated test to remove outdated retry logic and added new test implementation for event-driven resource checking
monitor_resources.go	Refactored monitoring to use select statement with timer and pause/resume channel, added broadcast functions for resource change events
management_api.go	Updated to dereference resourcesAvailable map directly instead of through pointer
main_test.go	Added new test case configuration for validating that outdated resource check results are not used
main.go	Extended ResourceManager with new mutexes and channels for event-driven coordination, updated resource reservation to use channel-based waiting instead of sleep polling
go.mod	Upgraded Go version to 1.23
.github/workflows/tests.yml	Updated CI workflow to use Go 1.23

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-12-29T03:05:00Z

monitor_resources_test.go

+
+	time.Sleep(3500 * time.Millisecond)
+
+	serviceOneHealthCheckResponse := getHealthcheckResponse(t, serviceTwoHealthCheckAddress)


The variable is named "serviceOneHealthCheckResponse" but it's actually fetching the response from serviceTwoHealthCheckAddress. This is confusing and should be renamed to "serviceTwoHealthCheckResponse" for clarity.

Copilot · 2025-12-29T03:05:01Z

main.go

 	rm.storeRunningServiceNoLock(name, runningService)
+	if runningService.activeConnections == 0 {
+		log.Printf("[%s] All connections closed, sending resourceChange event", name)
+		rm.broadcastResourceChanges(maps.Keys(serviceConfigByName[name].ResourceRequirements))


Potential deadlock: broadcastResourceChanges is called while serviceMutex is held (line 113). This method acquires resourceChangeByResourceMutex, which could lead to lock ordering issues if another goroutine tries to acquire these locks in a different order.

monitor_resources.go

Copilot · 2025-12-29T03:05:01Z

monitor_resources_test.go

+	//time.Sleep(1 * time.Second)
+	//statusResponse = getStatusFromManagementAPI(t, managementApiAddress)
+	//assertPortsAreClosed(t, []string{serviceOneHealthCheckAddress, serviceTwoHealthCheckAddress})
+	//verifyServiceStatus(t, statusResponse, serviceOneName, true, map[string]int{resourceName: 11})
+	//verifyServiceStatus(t, statusResponse, serviceTwoName, false, map[string]int{resourceName: 0})
+	//verifyTotalResourcesAvailable(t, statusResponse, map[string]int{resourceName: 11})
+	//verifyTotalResourceUsage(t, statusResponse, map[string]int{resourceName: 10})
+


This commented-out code block (lines 141-147) should be removed if it's not needed. Leaving large blocks of commented code reduces code maintainability and can cause confusion about whether it should be used or not.

Suggested change

//time.Sleep(1 * time.Second)

//statusResponse = getStatusFromManagementAPI(t, managementApiAddress)

//assertPortsAreClosed(t, []string{serviceOneHealthCheckAddress, serviceTwoHealthCheckAddress})

//verifyServiceStatus(t, statusResponse, serviceOneName, true, map[string]int{resourceName: 11})

//verifyServiceStatus(t, statusResponse, serviceTwoName, false, map[string]int{resourceName: 0})

//verifyTotalResourcesAvailable(t, statusResponse, map[string]int{resourceName: 11})

//verifyTotalResourceUsage(t, statusResponse, map[string]int{resourceName: 10})

Copilot · 2025-12-29T03:05:01Z

main.go

+			handleNotEnoughResource(requestingService, outputError, true, resource, currentlyAvailableAmount, resourceRequirements[resource])
 			return &resource
 		}
+		//todo: maxwaittime


TODO comment without a clear action plan or issue reference. Consider either implementing this or adding a reference to a tracking issue, or removing the comment if it's not needed.

Suggested change

//todo: maxwaittime

// NOTE: no maximum wait time is enforced here; callers are expected to wait until resources become available.

Copilot · 2025-12-29T03:05:02Z

main.go

 	runningService.stderrWriter.FinalFlush()
 	releaseResourcesWhenServiceMutexIsLocked(service.ResourceRequirements)
 	delete(resourceManager.runningServices, service.Name)
+	resourceManager.broadcastResourceChanges(maps.Keys(service.ResourceRequirements))


Potential deadlock: broadcastResourceChanges is called while serviceMutex is held (line 1458). This is the same issue as line 113 - calling a method that acquires resourceChangeByResourceMutex while holding serviceMutex can lead to lock ordering issues and potential deadlocks.

Copilot · 2025-12-29T03:05:02Z

monitor_resources.go

+			if !ok {
+				panic("pauseResumeChan closed unexpectedly, crashing to avoid infinite loop")
+			}
+			timer.Stop()


Timer is stopped (line 28) but not drained. After calling Stop(), if the timer has already fired, the channel may still contain a value. This should be drained to avoid a race condition. Consider using a select with default case to drain the channel after stopping.

Suggested change

timer.Stop()

if !timer.Stop() {

select {

case <-timer.C:

default:

}

}

Copilot · 2025-12-29T03:05:02Z

monitor_resources.go

+	resourceManager.resourceChangeByResourceMutex.Unlock()
+}
+
+func UnpauseResourceAvailabilityMonitoring(resourceName string) {


Function name is inconsistent with Go naming conventions. Public function names should be PascalCase, but should also follow consistent patterns. Consider renaming to "unpauseResourceAvailabilityMonitoring" (lowercase first letter) if this is meant to be package-private, or ensure it follows a consistent naming pattern with other public functions in the package.

Suggested change

func UnpauseResourceAvailabilityMonitoring(resourceName string) {

func unpauseResourceAvailabilityMonitoring(resourceName string) {

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 5 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

management_api.go

main.go

Copilot · 2026-01-15T02:34:40Z

README.md

 - `listen_port`: Port the service listens on
- `is_running`: Whether the service is currently running
+- `status`: stopped, waiting_for_resources, starting or running.
 - `active_connections`: Number of active connections to the service


The documentation field 'active_connections' is outdated and no longer exists in the API. According to the changes in management_api.go, this should document 'waiting_connections' and 'proxied_connections' as separate fields instead.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-15T02:48:59Z

monitor_resources.go

+func (rm ResourceManager) broadcastResourceChanges(resources iter.Seq[string], recheckNeeded bool) {
+	for resource := range resources {
+		rm.broadcastResourceChangeWhenResourceChangeByResourceMutexIsLocked(resource, recheckNeeded)
+	}
+}


The function broadcastResourceChanges calls broadcastResourceChangeWhenResourceChangeByResourceMutexIsLocked which, based on its name, expects resourceChangeByResourceMutex to already be locked. However, this function does not acquire the mutex before calling it. This function is called from incrementConnection (line 119 in main.go) and cleanUpStoppedServiceWhenServiceMutexIsLocked (line 1527 in main.go), both of which only hold serviceMutex. This will cause race conditions when accessing resourceChangeByResourceChans. Add mutex locking: acquire resourceChangeByResourceMutex at the start of this function and release it after the loop completes.

util_test.go

monitor_resources.go

Copilot · 2026-01-15T02:49:00Z

main.go

+	if interrupted {
+		return nil, fmt.Errorf("interrupt signal was received")
+	}
+


This is a duplicate check of the one on lines 745-746. The second check is redundant and can be removed to simplify the code.

Suggested change

if interrupted {

return nil, fmt.Errorf("interrupt signal was received")

}

Copilot

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 7 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

monitor_resources_test.go

Copilot · 2026-01-15T07:18:54Z

main.go

+		}
 		resourceManager.serviceMutex.Lock()
-		cleanUpStoppedServiceWhenServiceMutexIsLocked(&serviceConfig, runningService, false)
+		cleanUpStoppedServiceWhenServiceMutexIsLocked(&serviceConfig, runningService, true)


The third parameter 'true' is unclear without context. Consider extracting this to a named constant like 'shouldReleaseResources' to improve code readability.

Suggested change

cleanUpStoppedServiceWhenServiceMutexIsLocked(&serviceConfig, runningService, true)

shouldReleaseResources := true

cleanUpStoppedServiceWhenServiceMutexIsLocked(&serviceConfig, runningService, shouldReleaseResources)

Copilot · 2026-01-15T07:18:55Z

main.go

+			handleNotEnoughResource(requestingService, outputError, true, resource, currentlyAvailableAmount, resourceRequirements[resource])
+			return &resource
+		}
+		//todo: maxwaittime


Todo comment should be properly formatted with a capital 'T' and proper spacing: "TODO: max wait time".

Suggested change

//todo: maxwaittime

// TODO: max wait time

Copilot · 2026-01-15T07:18:55Z

main.go

 			stopService(*findServiceConfigByName(earliestLastUsedService))
 			continue
 		}
+		//TODO: add resource amounts


This TODO comment is vague. It should specify what resource amounts need to be added and where (e.g., "TODO: add resource amounts to log message").

Suggested change

//TODO: add resource amounts

// TODO: Add requested and currently available amounts for *missingResource to the following log message.

Copilot · 2026-01-15T07:18:55Z

config.go

 		Amount                    int    `json:"Amount"`
 		CheckCommand              string `json:"CheckCommand"`
-		CheckIntervalMilliseconds uint   `json:"CheckIntervalMilliseconds"`
+		CheckIntervalMilliseconds uint   `json:"CheckWhenNotEnoughIntervalMilliseconds"`


The struct field name 'CheckIntervalMilliseconds' doesn't match the JSON tag 'CheckWhenNotEnoughIntervalMilliseconds'. This will cause incorrect unmarshaling. The field name should be 'CheckWhenNotEnoughIntervalMilliseconds' to match the JSON tag.

Copilot · 2026-01-15T07:18:56Z

monitor_resources_test.go

-	verifyTotalResourceUsage(t, statusResponse, map[string]int{resourceName: 0})
+	verifyServiceStatus(t, statusResponse, serviceOneName, ServiceStateStopped, 0, 0, map[string]int{resourceName: 0})
+	verifyServiceStatus(t, statusResponse, serviceTwoName, ServiceStateStopped, 0, 0, map[string]int{resourceName: 0})
+	verifyResourceUsage(t, statusResponse, map[string]int{resourceName: 0}, map[string]int{resourceName: 1}, map[string]int{resourceName: 0}, map[string]int{resourceName: 0})


Multiple consecutive map[string]int parameters make this call hard to read and error-prone. Consider using a struct with named fields (e.g., ExpectedResourceUsage{Reserved: ..., Free: ..., Used: ..., Total: ...}) to improve clarity.

management-ui/index.html

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…conds

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated no new comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 11 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-15T07:57:04Z

main.go

+				"healthcheck timed out, not starting another healthcheck command: not enough time left for another HealthcheckInterval(%v) in StartupTimeout(%v)",
 				sleepDuration,
 				timeout,


The error message format string references variable names instead of using formatting placeholders. The message should format the duration values properly instead of printing "%dms" and "%s" literally.

Copilot · 2026-01-15T07:57:04Z

main.go

-				}
 			}
+		}
+		if !enoughOfResource && (!firstCheckNeeded || resourceConfig.CheckCommand == "") {


In the logic at line 1056, the condition checks (!firstCheckNeeded || resourceConfig.CheckCommand == "") which means resources without CheckCommand will immediately return as not enough resource without proper error logging when firstCheckNeeded is true. This seems inconsistent - resources without CheckCommand should be handled the same way regardless of the firstCheckNeeded flag.

Suggested change

if !enoughOfResource && (!firstCheckNeeded || resourceConfig.CheckCommand == "") {

if resourceConfig.CheckCommand == "" {

if !enoughOfResource {

handleNotEnoughResource(requestingService, outputError, false, resource, currentlyAvailableAmount, requiredAmount)

return &resource

}

} else if !firstCheckNeeded && !enoughOfResource {

Copilot · 2026-01-15T07:57:04Z

main.go

+	reservedAmount, ok := resourceManager.resourcesReserved[resource]
+	if !ok {
+		log.Printf(
+			"[%s] ERROR: Resource \"%s\" is missing from the list of the reserved resources. This shouldn't be happening",
+			requestingService,
+			resource,
+		)
+		reservedAmount = 0
+	}
+	enoughOfResource := requiredAmount <= currentlyAvailableAmount-reservedAmount
+	return currentlyAvailableAmount, enoughOfResource


There is a potential race condition in accessing resourceManager.resourcesReserved at line 1130. This field is accessed without holding serviceMutex, but it's modified in other places while holding serviceMutex. This could lead to inconsistent reads or race detector warnings. The access should be protected by acquiring serviceMutex first.

Copilot · 2026-01-15T07:57:05Z

main.go

+	//This is not optimal since it is blocked until the first resource change, which could take longer than the consequent ones.
+	//But in a scenario when there are enough resources, we need to wait for them all anyway, and if it's not enough, well, we're still waiting.


The comment "This is not optimal since it is blocked until the first resource change" describes a known limitation but doesn't explain the impact or why this approach was chosen. Consider expanding this comment to explain the tradeoffs and whether this is acceptable for the current use case.

Suggested change

//This is not optimal since it is blocked until the first resource change, which could take longer than the consequent ones.

//But in a scenario when there are enough resources, we need to wait for them all anyway, and if it's not enough, well, we're still waiting.

// This is not optimal since it is blocked until the first resource change for each

// resource, which could take longer than some of the subsequent changes. We accept

// this coarse‑grained blocking because:

// * this path is only used for resources with a CheckCommand, and the number of

// such resources per service is expected to be small;

// * keeping the logic as a simple "wait for the first change, then re‑evaluate"

// avoids more complex, concurrent coordination and reduces the chance of subtle

// race conditions in the resource manager; and

// * in the common case where enough resources eventually become available, the

// service must wait for all required resources anyway, so the additional

// latency from this blocking approach is acceptable for our current workloads.

Copilot · 2026-01-15T07:57:05Z

monitor_resources_test.go

+		}
+	}
+	time.Sleep(100 * time.Millisecond) //Give lmp time to catch up
+	//bug in the actual code here?


The comment at line 198 has a potential issue. It states "bug in the actual code here?" which is unclear. This comment should either be clarified with specific details about what bug is suspected, or it should be removed if the bug was already addressed.

Suggested change

//bug in the actual code here?

Copilot · 2026-01-15T07:57:06Z

main.go

 }

-func findFirstMissingResourceWhenServiceMutexIsLocked(resourceRequirements map[string]int, requestingService string, outputError bool) *string {
+func findFirstMissingResourceWhenServiceMutexIsLocked(resourceRequirements map[string]int, requestingService string, outputError bool, firstCheckNeeded bool) *string {


The variable name 'firstCheckNeeded' is confusing and doesn't clearly convey its purpose. Based on the usage, it appears to control whether to wait for the first check command result. A clearer name would be 'shouldWaitForCheckCommand' or 'needsInitialCheckCommand'.

Copilot · 2026-01-15T07:57:06Z

management_api.go

+			free = resourceManager.resourcesAvailable[resourceName]
+		}


There is a potential race condition when accessing resourceManager.resourcesAvailable at line 69. This field should be protected by resourcesAvailableMutex according to the comment in the struct definition, but here it's accessed while holding serviceMutex. Either acquire resourcesAvailableMutex before reading, or ensure the locking strategy is documented and consistent.

Copilot · 2026-01-15T07:57:06Z

monitor_resources.go

+func (rm ResourceManager) broadcastFirstChangeIfMutexIsLocked(resourceName string) {
+	resourceChangeByResourceChans, ok := rm.checkCommandFirstChangeByResourceChans[resourceName]
+	if !ok {
+		return //map is not initialized for resources without CheckCommand, so it being missing is ok
+	}
+	sendSignalToChannels(resourceChangeByResourceChans, resourceName, "checkCommandFirstChangeByResourceChans", struct{}{})
+}
+func (rm ResourceManager) broadcastResourceChangeWhenResourceChangeByResourceMutexIsLocked(resourceName string, recheckNeeded bool) {
+	serviceChannels, ok := rm.resourceChangeByResourceChans[resourceName]
+	if !ok {
+		log.Printf("[Resource Monitor][%s] ERROR: resourceChangeByResourceChans map is not initialized", resourceName)
+		return
+	}
+	sendSignalToChannels(serviceChannels, resourceName, "resourceChangeByResourceChans", recheckNeeded)
+}


These functions use a receiver value type instead of a pointer receiver. Since they operate on and modify state in the ResourceManager (via locking and channel operations), they should use pointer receivers (*ResourceManager) for consistency with other methods like storeRunningService and incrementConnection.

Copilot · 2026-01-15T07:57:06Z

monitor_resources.go

+		resourceManager.resourceChangeByResourceMutex.Lock()
+		if len(resourceManager.resourceChangeByResourceChans[resourceName]) > 0 || len(resourceManager.checkCommandFirstChangeByResourceChans[resourceName]) > 0 {
+			timer.Reset(checkInterval)
+		}
+		resourceManager.resourceChangeByResourceMutex.Unlock()


The condition checks if there are items in the channels by checking the length, but channels can become empty between the check and the timer reset. This could lead to the timer not being reset when it should be. Consider using a more robust signaling mechanism or ensuring the check and reset are properly synchronized.

Copilot · 2026-01-15T07:57:06Z

main.go

+	resourceManager.resourceChangeByResourceMutex.Lock()
+	//This might be not necessary if there is no CheckCommand
+	for _, resourceToCheck := range resourceManager.checkCommandFirstChangeByResourceChans {
+		delete(resourceToCheck, requestingService)
+	}
+	resourceManager.resourceChangeByResourceMutex.Unlock()


The comment at line 1085 states "This might be not necessary if there is no CheckCommand" which indicates uncertainty about the code's behavior. Either the cleanup is necessary or it isn't - this should be clarified and the comment updated to explain when and why this cleanup is needed.

perk11 force-pushed the resourse-check-on-event branch from 227d614 to f514e4e Compare December 28, 2025 00:53

perk11 requested a review from Copilot December 29, 2025 03:01

Copilot started reviewing on behalf of perk11 December 29, 2025 03:01 View session

Copilot AI reviewed Dec 29, 2025

View reviewed changes

perk11 changed the title ~~Resourse check on event~~ Resource check on event Dec 29, 2025

perk11 force-pushed the resourse-check-on-event branch from 95af14b to 5549e36 Compare January 4, 2026 07:02

perk11 force-pushed the resourse-check-on-event branch from 9e58013 to 96f4f99 Compare January 15, 2026 02:32

perk11 requested a review from Copilot January 15, 2026 02:32

Copilot started reviewing on behalf of perk11 January 15, 2026 02:32 View session

perk11 force-pushed the resourse-check-on-event branch from 96f4f99 to c494ecf Compare January 15, 2026 02:33

Copilot AI reviewed Jan 15, 2026

View reviewed changes

perk11 requested a review from Copilot January 15, 2026 02:45

Copilot started reviewing on behalf of perk11 January 15, 2026 02:46 View session

Copilot AI reviewed Jan 15, 2026

View reviewed changes

perk11 requested a review from Copilot January 15, 2026 07:16

Copilot started reviewing on behalf of perk11 January 15, 2026 07:16 View session

Copilot AI reviewed Jan 15, 2026

View reviewed changes

perk11 added 13 commits January 15, 2026 01:23

Implement test

f943cd5

WIP

bc94965

WIP

08b0a58

Something working

216844a

bugfix

4c2def6

fixes

05ec3c7

message

e7b5f1b

bugfix

f5a8280

test fix

23bb41a

bugfix

aae3057

test passing

15bc1a8

WIP

0733789

Fix totalAvailable amount in the API

ea59b3e

perk11 and others added 22 commits January 15, 2026 01:23

Update main.go

a03ec09

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Fix field name

84d5b33

fix readme

3468ad5

Add a missing lock

87d4995

Remove duplicate check

65d3b7b

Document CheckCommand

26abfac

Todo update

afddf4d

implement connections sort order

28e5ca3

Update todo

8c295f1

Update todo

4801b34

Move tracking

3d8d5c2

Rework connections tracking

21c163c

Update findServiceInStatusResponse

e779c9b

unused fields

813d568

map sizes

50ff257

newline

cdf9765

comment update

52fbf16

Rename CheckIntervalMilliseconds to CheckWhenNotEnoughIntervalMillise…

0ea8bed

…conds

(feat) Display usage for stopped services in Admin UI

7aebfba

Todo updates

bc89c8f

Update management-ui/index.html

bf8594a

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

rename

e4a6c17

perk11 force-pushed the resourse-check-on-event branch from 90a451a to e4a6c17 Compare January 15, 2026 07:23

perk11 requested a review from Copilot January 15, 2026 07:23

Copilot started reviewing on behalf of perk11 January 15, 2026 07:24 View session

Copilot AI reviewed Jan 15, 2026

View reviewed changes

Update outputError to true

17ede01

perk11 requested a review from Copilot January 15, 2026 07:52

Copilot started reviewing on behalf of perk11 January 15, 2026 07:52 View session

Copilot AI reviewed Jan 15, 2026

View reviewed changes


		time.Sleep(3500 * time.Millisecond)

		serviceOneHealthCheckResponse := getHealthcheckResponse(t, serviceTwoHealthCheckAddress)

	//todo: maxwaittime
	// NOTE: no maximum wait time is enforced here; callers are expected to wait until resources become available.

-			timer.Stop()
+			if !timer.Stop() {
+				select {
+				case <-timer.C:
+				default:
+				}
+			}

	func UnpauseResourceAvailabilityMonitoring(resourceName string) {
	func unpauseResourceAvailabilityMonitoring(resourceName string) {

	if interrupted {
	return nil, fmt.Errorf("interrupt signal was received")
	}

	cleanUpStoppedServiceWhenServiceMutexIsLocked(&serviceConfig, runningService, true)
	shouldReleaseResources := true
	cleanUpStoppedServiceWhenServiceMutexIsLocked(&serviceConfig, runningService, shouldReleaseResources)

	//TODO: add resource amounts
	// TODO: Add requested and currently available amounts for *missingResource to the following log message.

-		if !enoughOfResource && (!firstCheckNeeded || resourceConfig.CheckCommand == "") {
+		if resourceConfig.CheckCommand == "" {
+			if !enoughOfResource {
+				handleNotEnoughResource(requestingService, outputError, false, resource, currentlyAvailableAmount, requiredAmount)
+				return &resource
+			}
+		} else if !firstCheckNeeded && !enoughOfResource {

		//This is not optimal since it is blocked until the first resource change, which could take longer than the consequent ones.
		//But in a scenario when there are enough resources, we need to wait for them all anyway, and if it's not enough, well, we're still waiting.

-	//This is not optimal since it is blocked until the first resource change, which could take longer than the consequent ones.
-	//But in a scenario when there are enough resources, we need to wait for them all anyway, and if it's not enough, well, we're still waiting.
+	// This is not optimal since it is blocked until the first resource change for each
+	// resource, which could take longer than some of the subsequent changes. We accept
+	// this coarse‑grained blocking because:
+	//   * this path is only used for resources with a CheckCommand, and the number of
+	//     such resources per service is expected to be small;
+	//   * keeping the logic as a simple "wait for the first change, then re‑evaluate"
+	//     avoids more complex, concurrent coordination and reduces the chance of subtle
+	//     race conditions in the resource manager; and
+	//   * in the common case where enough resources eventually become available, the
+	//     service must wait for all required resources anyway, so the additional
+	//     latency from this blocking approach is acceptable for our current workloads.

Resource check on event #122

Are you sure you want to change the base?

Resource check on event #122

Uh oh!

Conversation

perk11 commented Dec 28, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 29, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment