Timeout value should not be hard coded #1049

New Issue

claunia · 2026-01-29T16:56:36Z

claunia commented

2026-01-29 16:56:36 +00:00

Originally created by @markatosi on GitHub (Jan 9, 2026).

Version: 4.0

Target: 10.0

Steps to Reproduce:

If I'm signing an app for distribution this process can take longer than the hard-coded timeout to finish

In ElectronNET.LateImport.targets(525,5)

<Exec Command="$(_NpxCmd)" WorkingDirectory="$(ElectronPublishDirFullPath)" Timeout="900000" StandardOutputImportance="High" StandardErrorImportance="High" ContinueOnError="false" Condition="@(CopiedFiles->Count()) > 0">
      <Output TaskParameter="ExitCode" PropertyName="ExecExitCode"/>
    </Exec>

Originally created by @markatosi on GitHub (Jan 9, 2026).    * **Version**: 4.0   * **Target**: 10.0   Steps to Reproduce: If I'm signing an app for distribution this process can take longer than the hard-coded timeout to finish In ElectronNET.LateImport.targets(525,5) ``` <Exec Command="$(_NpxCmd)" WorkingDirectory="$(ElectronPublishDirFullPath)" Timeout="900000" StandardOutputImportance="High" StandardErrorImportance="High" ContinueOnError="false" Condition="@(CopiedFiles->Count()) > 0"> <Output TaskParameter="ExitCode" PropertyName="ExecExitCode"/> </Exec> ```

claunia added the bug label 2026-01-29 16:56:36 +00:00

claunia closed this issue

2026-01-29 16:56:36 +00:00

claunia commented

2026-01-29 16:56:37 +00:00

@FlorianRappl commented on GitHub (Jan 9, 2026):

Fair point. Was there a specific reason for the timeout @softworkz or was is "just" a safety net?

I am not sure that this qualifies as a bug, but it definitely would be worth refining.

@FlorianRappl commented on GitHub (Jan 9, 2026): Fair point. Was there a specific reason for the timeout @softworkz or was is "just" a safety net? I am not sure that this qualifies as a bug, but it definitely would be worth refining.

claunia commented

2026-01-29 16:56:38 +00:00

@softworkz commented on GitHub (Jan 9, 2026):

The purpose of that timeout was merely to avoid cases where things are hanging forever in CI builds.

At that time, my assumption was that a package build would not take longer than 15 minutes. No matter whether we call it a bug or not: we can easily increase to 20 or 30min for sure.

@softworkz commented on GitHub (Jan 9, 2026): The purpose of that timeout was merely to avoid cases where things are hanging forever in CI builds. At that time, my assumption was that a package build would not take longer than 15 minutes. No matter whether we call it a bug or not: we can easily increase to 20 or 30min for sure.

claunia commented

2026-01-29 16:56:38 +00:00

@markatosi commented on GitHub (Jan 9, 2026):

It's not a bug, it's a logic error but there's not an option for that in the issue reporting.

@markatosi commented on GitHub (Jan 9, 2026): It's not a bug, it's a logic error but there's not an option for that in the issue reporting.

claunia commented

2026-01-29 16:56:39 +00:00

@markatosi commented on GitHub (Jan 9, 2026):

In any case the local developer is the only person who should be making decisions about how long they want the process to go before timing out. If I want to set it to 5 trillion seconds then I should be able to do so.

@markatosi commented on GitHub (Jan 9, 2026): In any case the local developer is the only person who should be making decisions about how long they want the process to go before timing out. If I want to set it to 5 trillion seconds then I should be able to do so.

claunia commented

2026-01-29 16:56:40 +00:00

@softworkz commented on GitHub (Jan 9, 2026):

Well, with that argument, you can ask for any detail to be configurable. All this is about providing a nice and convenient way for everybody, which is working out-of-the-box without needing to care about all details.

You can always write your own build scripts, then you have total control about everything.

@softworkz commented on GitHub (Jan 9, 2026): Well, with that argument, you can ask for any detail to be configurable. All this is about providing a nice and convenient way for everybody, which is working out-of-the-box without needing to care about all details. You can always write your own build scripts, then you have total control about everything.

claunia commented

2026-01-29 16:56:41 +00:00

@markatosi commented on GitHub (Jan 9, 2026):

That's a straw man argument. Please re-read my comment. I am requesting exactly one thing to be configurable.

@markatosi commented on GitHub (Jan 9, 2026): That's a straw man argument. Please re-read my comment. I am requesting exactly one thing to be configurable.

claunia commented

2026-01-29 16:56:42 +00:00

@markatosi commented on GitHub (Jan 9, 2026):

I do have my own build scripts I was testing your build process and noted an issue. I'll go back to using my custom build process.

@markatosi commented on GitHub (Jan 9, 2026): I do have my own build scripts I was testing your build process and noted an issue. I'll go back to using my custom build process.

claunia commented

2026-01-29 16:56:42 +00:00

@softworkz commented on GitHub (Jan 9, 2026):

Please re-read my comment.

Let's do that. You wrote:

In any case the local developer is the only person who should be making decisions about how long they want the process to go before timing out. If I want to set it to 5 trillion seconds then I should be able to do so.

After I had said that we can adapt the timeout to accommodate for your case, you are saying you want 5 Trillion seconds.
And you are wondering about my reply?

@softworkz commented on GitHub (Jan 9, 2026): > Please re-read my comment. Let's do that. You wrote: > In any case the local developer is the only person who should be making decisions about how long they want the process to go before timing out. If I want to set it to 5 trillion seconds then I should be able to do so. After I had said that we can adapt the timeout to accommodate for your case, you are saying you want 5 Trillion seconds. And you are wondering about my reply?

claunia commented

2026-01-29 16:56:43 +00:00

@markatosi commented on GitHub (Jan 9, 2026):

5 Trillion seconds was (to me) just an absurd value to make a point. I apologize if it didn't come across that way.

@markatosi commented on GitHub (Jan 9, 2026): 5 Trillion seconds was (to me) just an absurd value to make a point. I apologize if it didn't come across that way.

claunia commented

2026-01-29 16:56:44 +00:00

@softworkz commented on GitHub (Jan 9, 2026):

Never mind, all good - neither did I want to appear harsh - I got "a trillion" other things running through my head and I thought we had a good solution already, that got me off-track ;-)

@softworkz commented on GitHub (Jan 9, 2026): Never mind, all good - neither did I want to appear harsh - I got "a trillion" other things running through my head and I thought we had a good solution already, that got me off-track ;-)

claunia commented

2026-01-29 16:56:44 +00:00

@markatosi commented on GitHub (Jan 9, 2026):

I ran osx-sign manually and watched the debug output and it ran quite quickly. electron-builder uses osx-sign under the hood, so I'm not sure what's going on. I'm not going to worry about it in any event it's no problem to sign the app after electronNet does it's thing.

@markatosi commented on GitHub (Jan 9, 2026): I ran osx-sign manually and watched the debug output and it ran quite quickly. electron-builder uses osx-sign under the hood, so I'm not sure what's going on. I'm not going to worry about it in any event it's no problem to sign the app after electronNet does it's thing.

claunia commented

2026-01-29 16:56:45 +00:00

@FlorianRappl commented on GitHub (Jan 9, 2026):

In general the signing should no take longer than 15 minutes. I am open to set it to, e.g., 30 minutes, but given that most CI/CD agents time out after 1 hour I think that would be unreasonably high (if the process hangs in there there is no way to notice that this is the issue).

I think in the OP case it would not matter - the problem should be somewhere else.

Should we close this one?

@FlorianRappl commented on GitHub (Jan 9, 2026): In general the signing should no take longer than 15 minutes. I am open to set it to, e.g., 30 minutes, but given that most CI/CD agents time out after 1 hour I think that would be unreasonably high (if the process hangs in there there is no way to notice that this is the issue). I think in the OP case it would not matter - the problem should be somewhere else. Should we close this one?

claunia commented

2026-01-29 16:56:45 +00:00

@softworkz commented on GitHub (Jan 9, 2026):

Well, this conversation made me look up our timings and I could see that:

Our .net publish to Linux (for a single arch) takes 15.5min (AzDevOps)
Yet, that is building tar.gz,deb,rpm,pac and AppImage (the time includes all the .net/MSBuild stuff that is happening before electron-builder is invoked
In a different/unrelated project we have, Apple notarization taking 3 min (also AzDevOps)

Even though we are building many packages, I'd say it's still plausible that a .net publish for Mac incl. notarization could take longer than 15 min. One could have ElectronHostHook dependencies which require native compilation - maybe, or build even more packages for one platform.

So I'd say let's close this by increasing to 30min does that sound fine for everybody?

@softworkz commented on GitHub (Jan 9, 2026): Well, this conversation made me look up our timings and I could see that: - Our .net publish to Linux (for a single arch) takes 15.5min (AzDevOps) Yet, that is building tar.gz,deb,rpm,pac and AppImage (the time includes all the .net/MSBuild stuff that is happening before electron-builder is invoked - In a different/unrelated project we have, Apple notarization taking 3 min (also AzDevOps) Even though we are building many packages, I'd say it's still plausible that a .net publish for Mac incl. notarization could take longer than 15 min. One could have ElectronHostHook dependencies which require native compilation - maybe, or build even more packages for one platform. So I'd say let's close this by increasing to 30min does that sound fine for everybody?

claunia commented

2026-01-29 16:56:45 +00:00

@markatosi commented on GitHub (Jan 10, 2026):

I'm fine with closing this. I'm signing outside of the electron build process anyway at this point in time. I would like to mention though that Notarization speed is somewhat dependent on the user's internet bandwidth and size of their app. If one's bandwidth is low the notarization process can drag on... like mine is at the moment due to where I currently am it just takes forever to upload the zip to the apple notarization servers.

The apple approval side is generally fast but sometimes will be obscenely slow for mysterious reasons. That being said, signing and notarization are things that are easily handled outside of electronNet.

I finally got some rest so I'm no longer a grumpy sour-puss.

@markatosi commented on GitHub (Jan 10, 2026): I'm fine with closing this. I'm signing outside of the electron build process anyway at this point in time. I would like to mention though that Notarization speed is somewhat dependent on the user's internet bandwidth and size of their app. If one's bandwidth is low the notarization process can drag on... like mine is at the moment due to where I currently am it just takes forever to upload the zip to the apple notarization servers. The apple approval side is generally fast but sometimes will be obscenely slow for mysterious reasons. That being said, signing and notarization are things that are easily handled outside of electronNet. I finally got some rest so I'm no longer a grumpy sour-puss.

claunia commented

2026-01-29 16:56:46 +00:00

@softworkz commented on GitHub (Jan 21, 2026):

Will be fixed by https://github.com/ElectronNET/Electron.NET/pull/1013 (doubled timeout)

@softworkz commented on GitHub (Jan 21, 2026): Will be fixed by https://github.com/ElectronNET/Electron.NET/pull/1013 (doubled timeout)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Electron.NET#1049