text:
Linking issue dependencies fails (API returns 500 error)

Description
Okay, we're really lost in debugging this for hours now on Codeberg. A live meeting with 5 people cannot figure out what's exactly going on. Let's start from the beginning:
On Codeberg.org, you can no longer link issue dependencies. The API call returns an error 500 with the error message in the gitea.log:
2022/04/10 18:38:42 ...api/v1/repo/issue.go:276:SearchIssues() [E] CountIssues: unable to get one row result when CountIssues, row count=0

Now of course we thought of a recent regression and reverted to pre-1.16.5: still happening. We tried to reproduce on try.gitea.io and on codeberg-test: not happening.
We tried moving a whole database snapshot into our air gapped staging instance: Not happening, not reproducible, everything fine it seems (debugging there is a bit complicated, but we tried
"https://codeberg.org/api/v1/repos/issues/search?q=smtp&priority_repo_id=453&type=all&_=164961674595"

and got many results, whereas on Codeberg we still get 500.
Accepting that we can probably only approach the issue on our real production server, @Gusted worked out some patches for us to get more information.
Printing the generated SQL query for the function by XORM, and executing this ourselves in MySQL, worked fine and returned the correct information (about 9000 in our case).
We then checked the length of the return value of models.Issues here to see if it's an issue with countIssues or if it's an underlying issue of the options query. And the return value here was zero (0), so it indicates an issue with the query options that was being passed down.
This indicates that the query is correct, but when XORM is executing it, it will not return anything.
So this seems to be a scaling issue to us, maybe because this passes the id's of all the public repos + the further issues a user has access to, which is, 17000+ on our instance. (Maybe a point for further optimization, e.g. extend the query to allow all repos with is_private = false + explicitly private repos a user has access to?)
Also very relevant according to blame: #19244, and especially this comment, as we can't explain why this would ever return something else than 1 row from the `SELECT COUNT`` call.
Please note that our tested version includes that pull request, because @6543 pushed a cherry-pick to our branch. Of course we also tried reverting it, but - still broken.
That's where we currently are. The SQL log contains many question marks, about 17k, for each repository. That's about how many question marks we see when thinking about how to further approach this. We appreciate any help. Thank you!
Gitea Version
https://codeberg.org/Codeberg/gitea/commit/99e133b593fef813188e1e6469c65c9a11ec258a
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
git version 2.30.2
Operating System
Debian GNU/Linux 11
How are you running Gitea?
custom fork / deployment, see commit ref above
Database
MySQL

I think it's still a bug, maybe caused by GROUP BY.
SELECT * FROM ...  => always 1 rows
SELECT * FROM ... GROUP BY ...  => maybe 0 or many rows.
The key problem is that if it is the case, then the result of the old CountIssues (row[0]) is still incorrect and need to be fiexed ......

Printing the generated SQL query for [the function by XORM](https://github.com/go-gitea/gitea/blob/ee769f7459ffba310563cd735f503d3d7576da60/models/issue.go#L1520), and executing this ourselves in MySQL, worked fine and returned the correct information (about 9000 in our case).

Can you share the SQL for CountIssues?

Please see http://paste.debian.net/hidden/73165403/ for the SQL query we ran (manually interpolating the values).
Running it results in
count
9966

so I'm sorry if I was unclear before: Of course it returned one row with the value of about 9k (or 10k actually), and not that many rows.

The SQL looks correct. And the result is correct too.
Since everything seems correct, I can not understand how the row count=0 failure occurs, either ........
I suspect there are something missing or inconsistent. And according to the comment "We tried moving a whole database snapshot into our air gapped staging instance: Not happening, not reproducible, everything fine it seems", there must be something different.
Another question is that is the code exactly the same between Codeberg Gitea and Official Gitea?

Another question is that is the code (CountIssues related) exactly the same between Codeberg Gitea and Official Gitea?

I can't see any difference. Codeberg commits are always prefixed with CB/. The blame shows that nothing is touching these functions:
https://codeberg.org/Codeberg/gitea/blame/branch/codeberg-1.16/models/issue.go
Since we can't reproduce in our staging instance with the Codeberg binary yet, we don't really have a way to hunt this down with the upstream code. We can't just deploy the plain Gitea on production I fear ...

I have an idea about how to debug the problem.
Maybe we can build Codeberg-Gitea with a special flag (eg: ./gitea-codeberg my-test-issue), and use the special flag to run SearchIssues / CountIssues directly with the specialized options to trigger the bug. Then we just put this test binary to production server, then test with the production database without any downtime.
If the special flag can trigger the bug, then it gives us the chance to find the root case.
If the special flag can not trigger the bug either ..... it must be impossible, no reason to explain it .....

I like this idea, in fact I had a similar idea about trying to produce a minimal reproducible thing (e.g. a fresh binary with only the XORM call).
I think we can do this, provided that the binary does not modify any data or execute stuff (we already considered spawning a second Gitea instance, but we'd have to make sure it doesn't e.g. trigger Matrix hooks, run queues etc).

https://stackoverflow.com/questions/32973835/mysql-sometimes-erroneously-returns-0-for-count
And someone said that it could also be a mysql bug 😂

I like this idea, in fact I had a similar idea about trying to produce a minimal reproducible thing (e.g. a fresh binary with only the XORM call).
I think we can do this, provided that the binary does not modify any data or execute stuff (we already considered spawning a second Gitea instance, but we'd have to make sure it doesn't e.g. trigger Matrix hooks, run queues etc).

IIRC there are some Gitea sub commands like admin or doctor, it only do some database work.

You may can also add a db user with read-only permissions to be sure nothing is changed?

Notable in the stackoverflow thread is that count() can return 0 when nothing matches. I wasn't aware of that, but we should keep that in mind for further debugging.

a db user with read-only permissions

Yeah, but I also feared that it would read some queue and see it would need to fire some webhooks etc. Using a subcommand that only runs the affected query appears to be safe, though (not starting the normal Gitea app itself).

The error log line that appears on the 500 error is the one from the initial comment:
2022/04/10 18:38:42 ...api/v1/repo/issue.go:276:SearchIssues() [E] CountIssues: unable to get one row result when CountIssues, row count=0

see Edit above for the error. We tried with 10.5.13, still working. 10.6.7 is broken, too. We'll continue investigating.

OMG, I have a MariaDB 10.6.7 with 2T data in production 😭 I think I will take a look at this problem too .....

It's probably a very edge case, though. And it's not breaking any data at least, only the read query. :)

We did more test, even simple queries fail with more that 1000 placeholders since mariadb 1.5.15 or 14 (which we did not test)

Awesome! @lunny that's why I disagree to hide the error.
@fnetX Do you know which version of MariaDB has such bug while which doesn't? Is there any bug report on MariaDB side?

For a keyword search, repository id placeholder cannot be avoid. Maybe we need to limit it and give a warning in search result page that only display max less 1000 results.

Unable to reproduce from my side:
$paramCount = 9000;
$paramMarks = str_repeat('?,', $paramCount);
$paramMarks = substr($paramMarks, 0, -1);
$paramValues = range(1, $paramCount);

$stm = $pdo->query("SELECT @@VERSION");
print_r($stm->fetchAll(PDO::FETCH_ASSOC));

$sql = "SELECT COUNT(id) FROM ticket WHERE id IN ($paramMarks)";
# echo "$sql\n";
$stm = $pdo->prepare($sql);
$stm->execute($paramValues);
print_r($stm->fetchAll(PDO::FETCH_ASSOC));

$ php db-test-tmp.php
Array
(
    [0] => Array
        (
            [@@VERSION] => 10.6.7-MariaDB-log
        )

)
Array
(
    [0] => Array
        (
            [COUNT(id)] => 1
        )

)

@wxiaoguang
Weird, we can.
It gets even more crazy. Preparing the statement fails with > 65535 parameters with a proper error "too many placeholders", but between 1000-65535 even executing works but fetching results fail.

OK, I can reproduce it now with pure SQL. It's really a serious bug .........
100
PREPARE s FROM 'SELECT COUNT(id) FROM ticket WHERE id IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)';

EXECUTE s USING 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100;

+-----------+
| COUNT(id) |
+-----------+
|         1 |
+-----------+
1 row in set (0.003 sec)

1001
PREPARE s FROM 'SELECT COUNT(id) FROM ticket WHERE id IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)';

EXECUTE s USING 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710,711,712,713,714,715,716,717,718,719,720,721,722,723,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,742,743,744,745,746,747,748,749,750,751,752,753,754,755,756,757,758,759,760,761,762,763,764,765,766,767,768,769,770,771,772,773,774,775,776,777,778,779,780,781,782,783,784,785,786,787,788,789,790,791,792,793,794,795,796,797,798,799,800,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,820,821,822,823,824,825,826,827,828,829,830,831,832,833,834,835,836,837,838,839,840,841,842,843,844,845,846,847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,919,920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,938,939,940,941,942,943,944,945,946,947,948,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,964,965,966,967,968,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,986,987,988,989,990,991,992,993,994,995,996,997,998,999,1000,1001;

Query OK, 0 rows affected (0.002 sec)

@wxiaoguang

PHP has emulated prepared statements ....

Not when using mysqli instead of PDO which I did for my tests. They fails as your pure SQL test does.
Also it is strange that it is a recent regression in mariadb since 10.5.13 is still okay and only the recently released 10.5.15 is broken. I do consider this a mariadb bug since there is a proper error when really hitting the placeholder limit (>65535).

I opened an issue for MairaDB: https://jira.mariadb.org/browse/MDEV-28316

OK, I can reproduce it now with pure SQL. It's really a serious bug .........
I think it's worth to report it to MariaDB issue tracker .....
MariaDB: Server version: 10.6.7-MariaDB-log MariaDB Server
100
PREPARE s FROM 'SELECT COUNT(id) FROM ticket WHERE id IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)';

EXECUTE s USING 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100;

+-----------+
| COUNT(id) |
+-----------+
|         1 |
+-----------+
1 row in set (0.003 sec)

1001
PREPARE s FROM 'SELECT COUNT(id) FROM ticket WHERE id IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)';

EXECUTE s USING 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710,711,712,713,714,715,716,717,718,719,720,721,722,723,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,742,743,744,745,746,747,748,749,750,751,752,753,754,755,756,757,758,759,760,761,762,763,764,765,766,767,768,769,770,771,772,773,774,775,776,777,778,779,780,781,782,783,784,785,786,787,788,789,790,791,792,793,794,795,796,797,798,799,800,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,820,821,822,823,824,825,826,827,828,829,830,831,832,833,834,835,836,837,838,839,840,841,842,843,844,845,846,847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,919,920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,938,939,940,941,942,943,944,945,946,947,948,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,964,965,966,967,968,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,986,987,988,989,990,991,992,993,994,995,996,997,998,999,1000,1001;

Query OK, 0 rows affected (0.002 sec)

Amazing.

Already fixed upstream, but not released yet.
https://jira.mariadb.org/browse/MDEV-27937

Still, as the next (default) limit will be 65535 parameters, I think this query should be optimized.

Maybe we need to limit it and give a warning in search result page that only display max less 1000 results.

Doesn't this mean that large instance just won't have working issue dependency linking?
Where do the repo id's come from? All public repos, or all repos where a matching issue was found? Because when searching for some title, it's kinda weird to see soo many results for a simple title query anyway. I'd want to mainly see repos I'm associated with, and only then more results, probably.
I get right that the query does not simply provide all public repos, right?

What if we modify the code a bit to avoid passing all the repoIDs:
diff --git a/models/issue.go b/models/issue.go
index b1fa2d02a..1957e570c 100644
--- a/models/issue.go
+++ b/models/issue.go
@@ -1195,6 +1195,7 @@ func GetIssuesByIDs(issueIDs []int64) ([]*Issue, error) {
 type IssuesOptions struct {
        db.ListOptions
        RepoIDs            []int64 // include all repos if empty
+       RepoCond           builder.Cond
        AssigneeID         int64
        PosterID           int64
        MentionedID        int64
@@ -1289,6 +1290,10 @@ func (opts *IssuesOptions) setupSessionNoLimit(sess *xorm.Session) {
                applyReposCondition(sess, opts.RepoIDs)
        }

+       if opts.RepoCond != nil {
+               sess.And(opts.RepoCond)
+       }
+
        switch opts.IsClosed {
        case util.OptionalBoolTrue:
                sess.And("issue.is_closed=?", true)
diff --git a/routers/web/repo/issue.go b/routers/web/repo/issue.go
index 3ca193a15..7ab1dae01 100644
--- a/routers/web/repo/issue.go
+++ b/routers/web/repo/issue.go
@@ -2227,7 +2227,7 @@ func SearchIssues(ctx *context.Context) {
                                Page:     ctx.FormInt("page"),
                                PageSize: limit,
                        },
-                       RepoIDs:            repoIDs,
+                       RepoCond:           models.SearchRepositoryCondition(opts),
                        IsClosed:           isClosed,
                        IssueIDs:           issueIDs,
                        IncludedLabelNames: includedLabelNames,

To handle all similar problems gracefully in future, some improvements:

Make XORM's Count return an error if the result is 0 row.
Make XORM report warnings for SQLs with more than xxxx parameters (eg: 16384), then users/developers can know there is something needed to be refactored, they have enough time to optimize the query before the hard limit comes.

Doesn't this mean that large instance just won't have working issue dependency linking?

Maybe codeberg is one of the largest one, and usually there shouldn't be so many repo IDs

What if we modify the code a bit (using sub query) to avoid passing all the repoIDs:

It has Pros and Cons.

Pros: it seems to resolve the large-amount-repoID problem.
Cons: it may have other performance problems and is still difficult to be optimized if there is a performance problem.

I believe knowing the logic fully is the precondition to make optimizations (as the question "where do the repo id's come from"). Maybe it could be optimized from the logic side fundamentally.

And, to handle all similar problems gracefully in future, some improvements:

Make XORM's Count return an error if the result is 0 row.
Make XORM report warnings for SQLs with more than xxxx parameters (eg: 16384), then users/developers can know there is something needed to be refactored, they have enough time to optimize the query before the hard limit comes.

When having more than 65535 parameter there will be a proper error while preparing the statement.
The current behaviour between 1000 and 65535 where 0 rows are returned silently is a bug with unexpected behaviour.
It is different from having just max placeholders down to 999.

we have to use xorm builder so we create join querys and not In 1....100k querys
where go code insert the constrains

->  #19475

authors: 6543 Gusted ashimokawa fnetX lunny luwol03 wxiaoguang

repo: go-gitea/gitea


text:
Feishu webhook of issue update not linking to full issue url

Feature Description
I hope webhook of issue update include issue url. I find it strange commit webhook has URL while issue webhook notifications has no URL, which I usually would use more frequently,
Screenshots
No response

I see only
{
  "msg_type": "text",
  "content": {
    "text": "#2 tst1\r\n[org/repo1] Issue closed: #2 tst1 by user1"
  }
}

when using Feishu webhook.

@xgdgsc which version of gitea are you using?

Just downloaded latest release 1.19.3

I will fix this later.

hi @xgdgsc, I have submitted a Pull Request to fix this issue. Since the official documentation states that custom bots do not support hyperlink functionality, simply adding it without making some formatting changes would result in an unappealing output. Therefore, I have modified the formatting of the output. You can try using a custom bot. I have previously written one that you can refer to. The repository is located here: webhook2group

The commit notification message already has the url, which is fine and clickable. So I think just adding the url to the text would be fine? I' ve never used any custom bot before, just used the webhook bot.

The commit notification message already has the url, which is fine and clickable. So I think just adding the url to the text would be fine? I' ve never used any custom bot before, just used the webhook bot.

Yeah, my PullRequest fix this.

source: gharchive/issue

authors: Makonike techknowlogick xgdgsc

license: MIT

license_type: permissive

license_source: github-api


text:
timetracking popover disappears on hover

Description
Bildschirmaufzeichnung vom 2023-06-11, 21-27-52.webm
When opening the timetracking popover from navbar and trying to click the stop/delete button, the whole popover disappears when hovering.
Gitea Version
1.20.0+rc0
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Docker (Root)
Database
None

It should have been fixed by #25134

https://github.com/go-gitea/gitea/pull/25134#issuecomment-1582585081 (the change 5)

authors: denyskon wxiaoguang


text:
Webhook Test not working when Webhook not active

Description
When clicking "Test" on a Gitea webhook which is not active, the Test will always fail.
This can be problematic as one would like to test the functionality of a webhook prior to actually activating it. This in turn makes the user believe the webhook is simply not working.
Gitea Version
1.20.1
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Helm Chart in K8s.
Database
None

I think we should disable the test block in ui when webhook is active.

@yp05327 Needs your feedback on this..

I think we should disable the test block in ui when webhook is not active.

There's a use case as @Timoses said as following, so it is not a good idea to simply disable it.

This can be problematic as one would like to test the functionality of a webhook prior to actually activating it.

There's also a bug in webhook test(#24599), so we need do many changes to the whole design.

Yes, correct, I leave it you, for final decision. 💯

There's also a bug in webhook test(https://github.com/go-gitea/gitea/pull/24599), so we need do many changes to the whole design.

I wait till this fix.

You are welcome to create PRs for this. 😄


text:
Agit workflow instructions do not work

Description
I've followed instructions in https://docs.gitea.com/usage/agit-setup but could not make a pull request automatically created.
Logs of Gitea also don't mention anything.
$ git push origin HEAD:refs/for/master -o title="Test title" -o topic="Test topic" -o description="Test description"
To git.osgeo.org:postgis/postgis.git
 * [new reference]       HEAD -> refs/for/master

Gitea Version
1.20.5
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
The test I've run on try.gitea.io failed but in a different way:
[strk@c19:/tmp/test2(agit)] git push origin HEAD:refs/for/master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 257 bytes | 257.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Gitea: Unexpected ref: refs/for/master
To try.gitea.io:strk/test2.git
 ! [remote rejected] HEAD -> refs/for/master (pre-receive hook declined)
error: failed to push some refs to 'try.gitea.io:strk/test2.git'

Database
None

Currently, the default branch name is main. The docs should be updated.

@strk Could you confirm git push origin HEAD:refs/for/main will fix your problem? The last word should be the base repository target branch name.

In our case the base repository target branch is still "master", but I confirm try.osgeo.org does work if I push to the target repository. I've yet to test doing this on try.osgeo.org and ideed it works (as long as -o topic is given).
Is it supposed to also work when pushing to fork instead of target repository ?

In our case the base repository target branch is still "master", but I confirm try.osgeo.org does work if I push to the target repository. I've yet to test doing this on try.osgeo.org and ideed it works (as long as -o topic is given).
Is it supposed to also work when pushing to fork instead of target repository ?

Pushing to fork will create a PR of the fork repository. In Agit workflow, there is no fork concept.

So, I've tried back to git.osgeo.org/gitea and neither pushing refs/for/master (the real name of target) nor refs/for/main triggered the creation of a pull request. Rather those refs were created in the origin repository:
[strk@c19:/usr/local/src/postgis/postgis(drop-obsoleted-strings)] git push origin HEAD:refs/for/main -o topic="test topic"
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 575 bytes | 575.00 KiB/s, done.
Total 6 (delta 4), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To git.osgeo.org:postgis/postgis.git
 * [new reference]       HEAD -> refs/for/main
[strk@c19:/usr/local/src/postgis/postgis(drop-obsoleted-strings)] git push origin HEAD:refs/for/master -o topic="test topic"
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To git.osgeo.org:postgis/postgis.git
 * [new reference]       HEAD -> refs/for/master

but I confirm try.osgeo.org does work if I push to the target repository.

Do you mean try.gitea.io?
So it works in try.gitea.io but doesn't work in your host, which is git.osgeo.org?

@lng2020 exactly, at least not for this repository: https://git.osgeo.org/gitea/postgis/postgis -- feel free to try !

@lng2020 exactly, at least not for this repository: https://git.osgeo.org/gitea/postgis/postgis -- feel free to try !

will look into it later

Currently, the default branch name is main. The docs should be updated.

I've filed https://github.com/go-gitea/gitea/pull/27652 doing ALSO this

Consulting the source code I saw that "proc-receive" git hook is used for Agit, and that hook is only supported by git starting at version 2.29 -- on git.osgeo.org we're currently runnign an older version of git, which might explain the problem.

I've added a note about 2.29 requirement in the docs too, in https://github.com/go-gitea/gitea/pull/27652

authors: lng2020 lunny strk


text:
Add MDX linter for docs directory.

Since Gitea's documentation are now building with docusaurus v3 which support MDX syntax. So some wrong syntax will break the documentation building. Maybe https://npmjs.org/eslint-plugin-mdx is a good choice.

Would mdx files be named .mdx? If so, we can distinguish by file extension for which linters run on what. Would not recommend putting MDX content into .md.

This can be closed as docs moved to https://gitea.com/gitea/docs.

authors: lunny silverwind


text:
Portainer webhook support

Feature Description
I am currently using Portainer to deploy and update docker-compose stacks hosted on my gitea instance. I would like to be able to add a proper webhook to automatically update my stacks when pushing to the repos. Currently I make it work using the Gitea webhook.
References :
https://docs.portainer.io/user/docker/stacks/webhooks
https://docs.portainer.io/user/docker/stacks/add#gitops-updates
Screenshots
No response

Maybe we can do that after #19307

Closing/Merging this into https://github.com/go-gitea/gitea/issues/1089
A (temporary) workaround, as an alternative to what you are doing, could be to send a webhook via Gitea Actions. Although your workaround may be more effective

authors: AR2000AR lunny techknowlogick


text:
Can't login with SMTP authentication

Hi guys,
Same issue here, if user already exists on base, login normal, but if doesn't exist user, get error on login.
[Macaron] 2016-11-01 14:42:07: Completed /user/login 500 Internal Server Error in 1.364496ms

Reference: https://github.com/gogits/gogs/issues/3824

Strange, on my Gogs in production, have this issue, but on my fork of Gitea is working without problems, I will try test with Gitea master branch.

Does Gitea master branch have the bug?

@lunny Tested with Ubuntu 16.04 compiled from source, worked fine. I think that can be closed this.

OK. Just close now. Please feel free to reopen it if you find further information.

authors: joubertredrat lunny


text:
Proposal: hook improvements

Here's a list of improvements for git and web hooks that might be of interest:

[ ] Global hook templates It would be useful to maintain a global hook list under admin's control that repo owners can choose from, update, etc. Git hooks could be either stored in the file-system or added to the database as text.

[ ] Some details may be locked or open for the end user (e.g. destination URL, a query parameter in the case of web hooks, or some configuration variable to pass the git hook).

[ ] Script webhooks There should be a type of web hook that triggers a local script instead of starting a POST.
[ ] Vetted hooks It would be nice to enable custom hooks in repo templates as a way for admins/users with permission to create "vetted" git hooks and allow users to use them.
[ ] Enforced hooks Another possibility is copying hooks even if the user has no permissions for them (i.e. forced by the admin/template ower---- with a warning, of course). That way admins can enforce policies, for example.

[ ] If an org owner has the proper permissions, they could enforce certain hooks for every repo that is created/transferred to the organization.

[ ] Configure hooks location (e.g. core.hooksPath) to solve issues like noexec file-systems.

Related: #1089

A palette of git hooks with useful functionality could be added too. For example.

Consider setting git config core.hooksPath:
By default Git will look for your hooks in the $GIT_DIR/hooks directory. Set this to different path, e.g. /etc/git/hooks, and Git will try to find your hooks in that directory, e.g. /etc/git/hooks/pre-receive instead of in $GIT_DIR/hooks/pre-receive.
The path can be either absolute or relative. A relative path is taken as relative to the directory where the hooks are run (see the "DESCRIPTION" section of githooks[5]).
This configuration variable is useful in cases where you’d like to centrally configure your Git hooks instead of configuring them on a per-repository basis, or as a more flexible and centralized alternative to having an init.templateDir where you’ve changed default hooks.

We could actually set this and avoid the no exec problem in gitea-repositories etc.

Consider setting git config core.hooksPath:

@zeripath Can this be generalized as "add configurable settings to .git/config on repo creation"? So other settings can be added (I don't know, there might be something else that's useful). For example, in app.ini:
[git]
CONFIG_TEMPLATE = git.config

Then, in git.config:
[core]
hooksPath = {GITEA_DIR}/hooks/{OWNER}/{REPO}

I guess we need to keep Gitea from managing them (e.g. overwrite them?), however.

Yeah that could very easily be done. Writing to the per repository git config is probably the best bet as then any git commands that try to touch the repo outside of Gitea automatically also get the settings.
I think it's find if Gitea touches other git config settings - they're our repos in the end.
We also need to manage how configs work with our temporary repos.

Script webhooks There should be a type of web hook that triggers a local script instead of starting a POST.

this point is basically related to issue 1089, isn't it?

@alexanderadam I'll link that issue here, since this is more comprehensive.

I am sorry to revamping a nearly 2 years old topic, but I am having this issue when running gitea with docker.
I mounted the disk containing /var/lib/docker/volumes with the noexec flag, this results in all the volumes in my docker images being noexec, included /data for gitea. This results in hook scripts which never run in my system.
Is there a workaround? As I understood the proposed API has not been implemented yet and I am not well versed enough with the project to contribute by myself.
Thanks!

How about adding the --template argument here?
https://github.com/go-gitea/gitea/blob/68704532c28cf09db96c988291b2f82c5e615984/modules/git/repo.go#L75
According to git-init(1):
TEMPLATE DIRECTORY
       Files and directories in the template directory whose name do not start
       with a dot will be copied to the $GIT_DIR after it is created.

       The template directory will be one of the following (in order):

       •   the argument given with the --template option;
       •   the contents of the $GIT_TEMPLATE_DIR environment variable;
       •   the init.templateDir configuration variable; or
       •   the default template directory: /usr/share/git-core/templates.

       The default template directory includes some directory structure,
       suggested "exclude patterns" (see gitignore(5)), and sample hook files.

       The sample hooks are all disabled by default. To enable one of the
       sample hooks rename it by removing its .sample suffix.

So another option would be to set the GIT_TEMPLATE_DIR environment variable in an specific setup


text:
Better builtin avatar generator

This PR fixes the builtin avatar generator.

The random background color makes some images very dirty. So now we only use white background for avatars.
We use left-right mirror avatars to satisfy https://github.com/go-gitea/gitea/issues/14799
Fix a small padding error in the algorithm

Screenshot:

Codecov Report

Merging #17707 (19fa794) into main (7a03473) will increase coverage by 0.01%.
The diff coverage is 88.09%.

@@            Coverage Diff             @@
##             main   #17707      +/-   ##
==========================================
+ Coverage   45.46%   45.48%   +0.01%
==========================================
  Files         802      805       +3
  Lines       89278    89697     +419
==========================================
+ Hits        40590    40797     +207
- Misses      42146    42358     +212
  Partials     6542     6542

Impacted Files
Coverage Δ

modules/avatar/identicon/block.go
41.66% <33.33%> (ø)

modules/avatar/identicon/polygon.go
84.61% <84.61%> (ø)

modules/avatar/identicon/identicon.go
92.59% <92.59%> (ø)

modules/avatar/avatar.go
45.71% <100.00%> (-2.02%)
:arrow_down:

models/gpg_key_common.go
59.67% <0.00%> (-4.84%)
:arrow_down:

models/unit/unit.go
41.09% <0.00%> (-2.74%)
:arrow_down:

modules/queue/workerpool.go
50.00% <0.00%> (-2.30%)
:arrow_down:

modules/queue/queue_bytefifo.go
59.28% <0.00%> (-0.60%)
:arrow_down:

routers/web/repo/view.go
40.22% <0.00%> (-0.49%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a03473...19fa794. Read the comment docs.

source: gharchive/pull-request

authors: codecov-commenter wxiaoguang


text:
Add pam account authorization check (#19040)

Backport #19040
https://huntr.dev/bounties/8d221f92-b2b1-4878-bc31-66ff272e5ceb/
Co-authored-by: ysf 34326+ysf@users.noreply.github.com

make lgtm work


text:
Fix docs for attachment MAX_SIZE default value

In the documents, the [attachment] MAX_SIZE default value should be 4.
Reference the source code modules/setting/attachment.go line 29.

I have found the #28100 change modules/setting/attachment.go line 16 MaxSize from 4 to 2048. It is correct???

Maybe it is the #28100 forget change the modules/setting/attachment.go line 29 from 4 to 2048 ??

It should be 2048.

@lng2020 have changed


text:
Revert "Show View at this point in history for every commit (#29122)"

Fix  #30098

Why should this be reverted and not fixed?

Why should this be reverted and not fixed?

At the moment, a complete fix needs more time, and "wiki" doesn't support such "file view at history point".
To make it easier to backport for 1.22, this is a quick fix IMO

Why should this be reverted and not fixed?

Quote my comment from #29122 :

Actually I have a question for this change: if there is no FileName, why it should show a link to the commit? The commit link is already shown in the second column. If I understand correctly, View at this point in history is only for viewing a "file", but not a "commit". I think the change 29122 is not right.

At the moment, a complete fix for "wiki" needs more time, and "wiki" doesn't support such "file view at history point". So even if you could check it is a wiki, no link could be used.
To make it easier to backport for 1.22, this is a quick fix IMO

The button does a similar thing as a click on "sha1" column

On the sha1 click you see the commit but with View at this point in history you see the repo at this commit
So the absolute best and also a easy fix is to check for wiki and then dont show the link
So the feature is not reverted and the bug is fixed

I do not understand why there should be a duplicate button on the UI.
The commit sha is already in the second column, so I do not think it is right to add one more button in the last column.

Hmm, sorry, I think I can see the point now. Will propose a new one.

Sorry for my misundestanding and sorry for bothering, the new PR: -> https://github.com/go-gitea/gitea/pull/30297/files?diff=split&w=1

authors: wxiaoguang zokkis


text:
Expose issue stopwatch toggling via API

.. #4327 automatically stops the stopwatch but this PR will be useful in case there
is a need to programmatically toggle the stopwatch.
Fixes https://github.com/go-gitea/gitea/issues/5942

Done @lafriks.


text:
Fix editor commit to new branch if PR disabled

Fixes #8371

Codecov Report

Merging #8375 into master will decrease coverage by <.01%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #8375      +/-   ##
==========================================
- Coverage   41.77%   41.76%   -0.01%
==========================================
  Files         496      496
  Lines       65610    65610
==========================================
- Hits        27409    27404       -5
- Misses      34684    34691       +7
+ Partials     3517     3515       -2

Impacted Files
Coverage Δ

routers/repo/editor.go
26.86% <33.33%> (ø)
:arrow_up:

models/unit.go
62.16% <0%> (-5.41%)
:arrow_down:

modules/log/event.go
64.61% <0%> (-1.03%)
:arrow_down:

routers/repo/view.go
42.53% <0%> (-1.02%)
:arrow_down:

modules/sync/unique_queue.go
89.28% <0%> (+10.71%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6ea7752...12fb9f7. Read the comment docs.

Please send back port to v1.9

https://github.com/go-gitea/gitea/pull/8400

backport PR done @guillep2k @lunny


text:
Create cannot handle custom type?

Your Question
Say I have this model:
type Demo struct {
	MyTime time.Time
}

If I run
if err := db.AutoMigrate(&Demo{}); gerr != nil {
	panic(err)
}

if err := db.Create(&Demo{
	MyTime: time.Now(),
}).Error; err != nil {
	panic(err)
}

It produces the SQL statements (MySQL):
CREATE TABLE `demos` (`my_time` datetime(3) NULL)

INSERT INTO `demos` (`my_time`) VALUES ('2021-01-19 18:19:25.824')

Cool, this looks right. But if I change the model like so:
type CustomTime time.Time

type Demo struct {
	MyTime CustomTime
}

And run this code:
if err := db.AutoMigrate(&Demo{}); gerr != nil {
	panic(err)
}

if err := db.Create(&Demo{
	MyTime: CustomTime(time.Now()),
}).Error; err != nil {
	panic(err)
}

It runs the same statements:
CREATE TABLE `demos` (`my_time` datetime(3) NULL)

INSERT INTO `demos` (`my_time`) VALUES ('2021-01-19 18:25:18.495')

But it also outputs this error:
sql: converting argument $1 type: unsupported type CustomTime, a struct

Am I doing something wrong here? I would think that since CustomTime is based on time.Time, and time.Time is handled properly, it should handle this properly. I'm not sure if this is a bug, or is simply unsupported for some reason.
The document you expected this should be explained
Declaring Models maybe?
Expected answer
A way to do this, or a reason it doesn't work.

https://gorm.io/docs/data_types.html

https://gorm.io/docs/data_types.html

Thank you, that helps. Is there a way to set a function (perhaps in the config) that is used as a Scanner/Valuer for all custom types that can't be converted?

Thank you, that helps. Is there a way to set a function (perhaps in the config) that is used as a Scanner/Valuer for all custom types that can't be converted?

no, the scanner, valuer is required by database/sql

no, the scanner, valuer is required by database/sql

authors: KyleKotowick jinzhu

repo: go-gorm/gorm


text:
版本号作为查询条件

表中有一列放的是版本号，格式是三段式，例如：1.2.21
现在想要根据这一列来进行查询，例如：查询版本号大于1.0.5的所有记录，数据库是MySQL8.0+，请问使用gorm应该如何实现，谢谢

@jinzhu 呼叫柱哥😁

https://stackoverflow.com/questions/34876711/mysql-query-compare-version-numbers


text:
Add initial gpg support

This PR adds support to use a Yubikey for GPG encryption and decryption.
There are still some large changes to be made based on the feedback in https://github.com/go-piv/piv-go/pull/138 and https://github.com/go-piv/piv-go/pull/137.
Once those are resolved, this code will be updated  to reflect those.

Thanks, but I'm going to preemptively say there's no way this package will ever support GPG/PGP. A large motivating factor for this project was leveraging more reasonable signing primitives on Yubikeys. See: https://blog.gtank.cc/modern-alternatives-to-pgp/. I defiantly do not want to carry any code for the PGP app, and that's beyond the scope of piv-go.
In the future, it may be better to reach out to a maintainer before sending a large PR like this?
Closing, since yeah... I don't see this as compatible with this project. You may want to fork if this is something you're looking to publish

That’s fine
The effort for me to maintain an open form or to upstream everything is the same cost.
I’ll separate out all the parts that allow me to use pgp support without rewriting the entire library to talk to the cards.
piv-go has all of the apdu primitives.
My issue is key size, I have constraints that require a 4096 bit key that the cards only support via pgp.

I need 4096 bit hardware backed keys.
I use S/MIME for email, and something else for signing commits (except on GitHub because reasons)

Sure, I just want to make clear that "I defiantly do not want to carry any code for the PGP app" also applies to internal refactors for this kind of thing (I don't have unlimited review time for OSS). If you need to use or modify the smartcard code, please fork it

That’s perfectly reasonable.
I’ll make this into a fork.
I already have one

authors: areese ericchiang

repo: go-piv/piv-go


text:
Operations import is missing from generated foo_client.go

Problem statement
Generated client/foo_client.go doesn't contain import for operations package.
Swagger specification
---
swagger: "2.0"
info:
  title: foo api
  version: "1.0.0"
paths:
  /version:
    get:
      responses:
        "200":
          description: foo version
          schema:
            type: string
      summary: foo version
      operationId: showVersion

Steps to reproduce
Put the above yaml into swagger.yaml and run
rm -rf ./pkg/foo_api && \
mkdir -p ./pkg/foo_api && \
docker run \
  --rm -it \
  --user "$(id -u):$(id -g)" \
  -e GOPATH=$HOME/go:/go \
  -v $HOME:$HOME \
  -w $(pwd) quay.io/goswagger/swagger \
  generate client -f ./swagger.yaml -t ./pkg/foo_api

Observe go failing to build the package:
$ go build ./pkg/foo_api/client/foo_client.go
go: finding github.com/go-openapi/strfmt v0.19.5
go: finding github.com/go-openapi/runtime v0.19.15
go: finding github.com/go-openapi/runtime/client latest
go: downloading github.com/go-openapi/runtime v0.19.15
go: extracting github.com/go-openapi/runtime v0.19.15
go: downloading github.com/go-openapi/strfmt v0.19.5
go: extracting github.com/go-openapi/strfmt v0.19.5
# command-line-arguments
pkg/foo_api/client/foo_client.go:101:13: undefined: operations

Environment
swagger version: v0.23.0 commit: 3596b40bedd4f06cc918767098568456d2ec2370
go version: go1.12.7 linux/amd64
OS: Ubuntu 16.04.5

Getting something similar here, explained on #2283.

Yeah definitely a bug when there is the trailing "api" string in the  name.

Duplicates #2293, which root causes the issue

I don't have 'api' name but 'operations' import is still missing. Version 0.30.5

authors: ToJen filinvadim fredbi keymone

repo: go-swagger/go-swagger


text:
Backticks appearing in tags are not properly handled

Problem statement
If schema data containing backticks end up in struct (etc.) tags of generated Go code, the tag generation is not handling quotation of tags properly. ( Outer quotes would need to be " instead of backtick with inner double quotes being escaped. One solution is to do this with all tags, but that would make the generated code ugly,  and go fmt doesn't clean it up.)
Swagger specification
Backticks are legal, e.g. in XMLObject, the name parameter is a string with no further restrictions ...
Steps to reproduce
I've attached a minimal extract from a real-world public schema (https://api.mouser.com/api/docs/ui/index) which ends up generating broken code.  Executed as (swagger generate client -f test.json.txt), here are the relevant bits:
// schema
"xml" : {
    "name" : "KeyValuePair`2",
    "wrapped" : true
}
// go IS
(...) `json:"ScheduledReleases" xml:"KeyValuePair`2"`

// go SHOULD
(...) "json:\"ScheduledReleases\" xml:\"KeyValuePair`2\""

test.json.txt
Unfortunately, you can't escape backticks within backticks, so Tags need to revert to double quotes containing escaped quotation marks ...
(Also, I'm well aware that this is terribly awfully unaesthetic style and it leaves me scratching my head asking myself what sort of a deranged monster would do such a thing, but as far as I can tell it's perfectly legal.)
Environment
swagger version: current (2020-11-13) master (  8831a62b )
go version:  go version go1.14.3 linux/amd64
OS:
$ lsb_release  -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.1 LTS
Release:	20.04
Codename:	focal

@fredbi  It's a pretty generous interpretation of 'enhancement' to not consider this a bug ;)
Would you all be open to a patch that inverts all applicable generated tags, i.e. use double quotes and escape double quotes within the tags, like so:
 "json:\"ScheduledReleases\" xml:\"KeyValuePair`2\""

This would fix all occurrences of similar behavior and the only objection I can think of is aesthetic. But as it's generated code which shouldn't be touched anyway, it would be an acceptable solution from my point of view. I would be willing to contribute a patch.

@a2800276  if you consider a patch, could you please separate the case when escaping is necessary (like adding a guard to detect the presence of a backtick)?

@fredbi That's what I was referring to ... I don't think it's possible to do that with the current  template system. Consider the main bit affected:
{{ pascalize .Name}} {{ template "schemaType" . }} `
  {{- $prop := . }}
  {{- range $i, $structTag := $.StructTags }}
    {{- if gt $i 0 }} {{ end }}
    {{- template "structTag" dict "Tag" $structTag "Schema" $prop }}
  {{- else }}
    {{- template "structTag" dict "Tag" "json" "Schema" $prop }}
  {{- end }}
  {{- if .XMLName }} xml:"{{ .XMLName }}"{{ end }}
  {{- if .CustomTag }} {{ .CustomTag }}{{ end }}`
{{ end }}

(from: generator/templates/structfield.gotmpl)
The backticks themselves are literals in the template and there are numerous fields to check for the existence of backticks in the values. If any of those values contain backticks, a different template  would have to be chosen. Compare that with escaping double quotes in all values and using double quotes instead of backticks for the surrounding quotes.
I agree that would be super ugly, but the ugliness is constrained the generated code that is rarely touched. I can try to put together a quick PoC to check whether this is as simple a fix as I presume ... I don't understand the code base well enough to contemplate how this could be done any other way without a complete rewrite of this mechanism. If you have any pointers, I'd be open to try though.
On a related note, I'm reluctant to start work on a fix because I can't get the unit tests in generator to pass. Is this a bug I should report or is there something I need to do beyond just calling go test?
I'm running tests using: $ go test ./generator the output is fairly large, because apparently the tests are logging to stderr, I'm attaching a copy of the output.
generator_test_results.txt

I don't think it's possible to do that with the current template system

@a2800276  consider making it a function in either struct.go or in the repo_template.go funcmap.

On a related note, I'm reluctant to start work on a fix because I can't get the unit tests in generator to pass. Is this a bug I should report or is there something I need to do beyond just calling go test?

./gen-debug.sh # <- this regenerate your bindata.go in debug mode (live template assets)
go test -v -failfast

Idea #1. The whole section starting with backtick:
{{ pascalize .Name}} {{ template "schemaType" . }} `
  {{- $prop := . }}
  {{- range $i, $structTag := $.StructTags }}
    {{- if gt $i 0 }} {{ end }}
    {{- template "structTag" dict "Tag" $structTag "Schema" $prop }}
  {{- else }}
    {{- template "structTag" dict "Tag" "json" "Schema" $prop }}
  {{- end }}
  {{- if .XMLName }} xml:"{{ .XMLName }}"{{ end }}
  {{- if .CustomTag }} {{ .CustomTag }}{{ end }}`
{{ end }}

could be replaced by a template method on object GenSchema to do the job of expanding all tags, e.g:
{{ pascalize .Name}} {{ template "schemaType" . }} {{ .PrintTags }}
{{ end }}

This would correspond in structs.go to something like:
func (g GenSchema) PrintTag() string {
 ....
}

@fedbi thanks for the pointers, I'll start poking around.
I'm afraid the generator tests are still failing, though:
$ cd generator
$ ./gen-debug.sh && go test -v -failfast > still_failing

still_failing.txt
Does the above run on your machine successfully? I'm using the "kevinburke" fork of go-bindata as suggested in the docs, maybe this advice is out of date?
The problem with the tests lies in assertImports, it's expecting:
"swagger_nogo030569067/packages_mangling/client/abc_linux"

as an import, but a fully qualified (if mangled) path is being generated:
"github.com/go-swagger/go-swagger/generator/swagger_nogo030569067/packages_mangling/client/abc_linux"

My problem is that the only other usage of assertImports (in generat_test.go) checks for  fully qualified paths, and that test passes. Both tests were introduced in the same commit. Unfortunately, I'm not able to judge what the correct & expected behavior is, but it seems that (at least) one of the cases is probably genuinely broken or wrong... Let me know whether I should open this as a separate issue ...

Yes, it works fine locally and on CI as well: all the tests pass.
It is okay to have a fully qualified package import. The regexp should match either way.
You may open this as a separate issue. It is likely that this is dealing with your build environment.

It is okay to have a fully qualified package import. The regexp should match either way.

The regexp matches the surrounding quotes ... So it needs to literally match the import statement. I'll have a look at CI and will raise a seperate issue if it doesn't become apparent why it's different here. Thanks!


text:
Registering custom formats for number, string in code generator

Problem statement
I would like the generator to use (decimal.Decimal)[https://github.com/shopspring/decimal] type to represent fields with type: number, format: decimal. The decimal format is not a part of the OpenAPI specs (as far as I can tell) so I can't expect this to be available in go-swagger. How ever, float64 is not acceptable for handling money.
Is there a way to plug-in / register custom format/types to the generator? I'm aware of strfmt but it doesn't seem to be possible to define the string formats for the generator (just when you're generating specs from code)
I would also like to configure the generator to use int instead of int64 for integers etc. I understand this is not necessarily ideal for everyone which is why I'd like it to be configurable.
Swagger specification
Money:
  type: object
  properties:
    amount:
      type: number
      format: decimal # non standard
      description: Amount is the monetary value
    currency:
      type: string
      format: currency
      description: 3 char currency code  # https://en.wikipedia.org/wiki/ISO_4217

Any way to do this now, any plans to support this in the future or would you accept this feature (configurable custom formats/types in the generator) if I find a solution?

I'd certainly accept a PR. You can perhaps build on the config file that was introduced for defining language support.
I think you'd have to define a map entry for the formats and a snippet for registering that format in strfmts. So all in all shouldn't be too difficult to make work.
The int64 there is a reason for that, because int is platform dependent. And some languages have a different default. So making a contract for your API that leaves ambiguity might not be ideal for a public API. But I do think you can use a similar approach here, although a builtin like this might be harder to implement.

@casualjim this could be provided by supporting it as an x-format-type no? Adding it to strfmt and plugging it into the other custom x-format-types we provide already? Is that what you had in mind as well?

authors: GlenDC casualjim hannson


text:
Add: add win32 send key event by pid support

Please provide Issues links to:

Issues: #125

Provide test code:

Description
...

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant vcaesar

repo: go-vgo/robotgo

license_source: bigquery


text:
使用 Sync2 同步一个没创建过的表时，如何指定字符集为 utf8mb4

现在生成的都是utf8的
也许创建数据库时，用utf8mb4作为默认排序规则时就可以。

use engine.CharSet().Sync2

authors: flowercodec lunny

repo: go-xorm/xorm


text:
Fix Clue Mock Gen package name conflict

Fix a bug where an alias is not used for the mocked package if it conflicts with one of the other intial imports (this was discovered with a package named testing, but it looks like it could also come up if it was named mock which would conflict with goa.design/clue/mock.
Bump version so it will be correct for a new release.

Codecov Report

Merging #259 (400dbed) into main (0005d44) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #259      +/-   ##
==========================================
- Coverage   94.33%   94.33%   -0.01%
==========================================
  Files          43       43
  Lines        2189     2187       -2
==========================================
- Hits         2065     2063       -2
  Misses         91       91
  Partials       33       33

Flag
Coverage Δ

micro
94.33% <100.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

mock/cmd/cmg/pkg/generate/mocks.go
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: codecov-commenter douglaswth

repo: goadesign/clue


text:
Ability to assign multiple roles to a user

Is your feature request related to a problem? Please describe.
It would be nice to be able to assign multiple roles to a user.
For example role 1 has x permissions, and role 2 has y permissions.
It would be nice to not have to create a third role with x and y permissions to cover both roles.

I would not describe this as an issue but as a feature request. If you want to add this feature to this API you're more than welcome but for now, I'm closing this issue @xXBlackHawkXx .

authors: gobeam xXBlackHawkXx

repo: gobeam/truthy


text:
Getting migrations state programmatically

Description
I need to be able to get the state of migrations programmatically in code. As I understand, the only option I have now is parsing the output of Migrator.Status(), and my code will break as soon as output formatting will change.
Or maybe there is another way to accomplish it?

Don't know what you mean with migration state exactly, but you can do  something like:
    Version string `db:"version"`
}

func GetAppliedMigrations(conn *pop.Connection) (migs []SchemaMigration, err error) {
    err = connection.RawQuery(`select "version" from schema_migration`).All(&migs)
    return
}```

And you'll get the version numbers of applied migrations in a list.

You can see unapplied migrations by listing and parsing names of files in your migration directory.

You can also apply migrations programmatically and for that purpose you need to know how many migrations were applied before because on error you might want to know how many steps you want to roll back.

authors: cmhakkim nmlc

repo: gobuffalo/pop


text:
ehp cant get cpu metrics

Describe the bug
resouce metrics use prometheus-adapter
v1beta1.metrics.k8s.io                 monitoring/prometheus-adapter   True        29h
也可以获取到cpu指标
k top pod -n monitoring httpserver-64db7f5658-7l9gc
NAME                          CPU(cores)   MEMORY(bytes)
httpserver-64db7f5658-7l9gc   0m           10Mi
ehpa
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

- lastTransitionTime: "2022-08-25T08:35:45Z"
    message: 'the HPA was unable to compute the replica count: failed to get cpu utilization:
      missing request for cpu'
    reason: FailedGetResourceMetric
    status: "False"
    type: ScalingActive

Environment (please complete the following information):

K8S Version: [e.g. 1.23]
Crane Version: [e.g. 0.7.0]
Browser [e.g. chrome, safari]

Hi @sunnoy , you can referring to doc to play with prometheus-adapter:  https://github.com/gocrane/crane/blob/main/docs/tutorials/effective-hpa-with-prometheus-adapter.zh.md

I just followed this document 。。。

Are you in chat group?

chat group name is 腾讯云原生技术交流10 ？

when use "Utilization" ,it need config container resouce limit and reqest
          resources:
            limits:
              cpu: 500m
            requests:
              cpu: 200m

https://github.com/gocrane/crane/pull/533

authors: qmhu sunnoy

repo: gocrane/crane


text:
New SVG UI glitches sometimes

Operating system or device, Godot version, GPU Model and driver (if graphics related):
windows 64, nvidia, 50a0e3f (it started to appear from the very first version with svg tho)
Issue description:

I have border=2 setting in editor settings. Look at the border of Edit, Run, Import buttons (left and bottom sides). It is thinner then others. And this is constantly changing. I mean if i move mouse over some other UI elements, this glitch will move somewhere else (totally randomly in the whole window)

That's likely a duplicate of #10461.

not sure. for me it starting appearing right on 22 August (99% sure). and it looks different to the other issue

#10523 try this branch and see if it worka.
The svg's probably have nothing to do with that.
In general there is vo svg used in the editor. Svg aupport imports svg files to textures.
Than those textures are displayed.
So this has to be casued by the styleboxes. And for them the borders worked.
So the polygon aa could be the case.
As i said just compile the brqnch of my pr and test again. Or wait ubtil it ia merged and than update this issue if it changed.

@toger5 it failed to compile
[Initial build] Linking Static Library ==> editor\editor.windows.tools.32.lib
editor\editor_icons.gen.h : fatal error LNK1136: invalid or corrupt file
scons: *** [editor\editor.windows.tools.32.lib] Error 1136
scons: building terminated because of errors.

i will wait for the merge. thank you.

@curly-brace have you removed editor_icons.gen.cpp ?

@curly-brace I just recoiled on windows and checks how it looks. item now really sure that #10523 would fix it.

@toger5 i'm not very good at c++, so i don't know why this happened. but i've just took source from your repo and put it in clean folder and launched compilation.. whatever, hope merge will succeed 👍

hm... okay than my tip is useless... lets see if it gets fixed with a merge.

it is a duplicate of #10461, also there is no such thing as an SVG UI (yet)

@akien-mga @curly-brace this can be closed.

just compiled efcafab6255ea78365e519ca3a13e9bf8b2a81d4 and this glitch is gone. awesome!

authors: akien-mga curly-brace djrm toger5

repo: godotengine/godot


text:
alpha border issue

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Ubuntu 17.04 - Godot v3.0.alpha.custom_build.3ae1cff
Issue description:

Sprites alpha border seems to be bit strange:

I used a completely white sprite in the example, there shouldn't be any gray outline.

Is "Fix Alpha Border" turned on in your import settings?

Yes I tried all options in the import docker, nothing fixes the issue

Don't forget to click on "Re-import"?

I don't think I'm that stupid :)

Would you mind sharing your sprite? or example project?

Oh right, in game it seems there's no problem, it's only the editor, just checked, still needs to be fixed.
godot-dbg.zip

I can confirm this issue.

me too

So, I am that stupid, sort of. So turns out I forgot about the stroke (in inkscape) so that's why there was the dark border. That being said, after fixing the images there still seems to be a problem here.
See attached project; both in editor & running game (for the complete solid white sprite - no blur):
godot-dbg.zip

FIxed by https://github.com/godotengine/godot/pull/12072?

Fixed by #12072.

authors: HummusSamurai Sslaxx akien-mga gamergamesz novemberist razvanc-r


text:
Implement yield_from()

Newer versions of Python implement yield_from(), which makes nesting co-routines easier.
You can mimic it in a coroutine with:
    func coroutine1():
        # do something
        yield()

     func coroutine2():
         # Do stuff with yields

         var sub_coroutine = coroutine1()
         while sub_coroutine.is_valid():
             sub_coroutine.resume()
             yield()

         # do more stuff with yielding

But with yield_from():
     func coroutine2():
         # Do stuff
         yield_from(coroutine1())
         # do more stuff

In case it isn't obvious, this is just a bit of syntactical sugar, so it is very low priority.

In 4.0 we are introducing the await keyword which can already do it: await coroutine().

authors: Spooner vnen


text:
Add an optional mechanism to detect infinite loops in gdscript

Hi,
It would quite reassuring if the debug version of godot had some sort of watchdog timer or any other optional mechanism that would detect and warn about infinite or way-too-long loops in gdscript.

This is not possible as it would mean to solve the halting problem.
http://en.wikipedia.org/wiki/Halting_problem

instead of trying to detect faulty code, there could be a "watchdog iteration counter" as a configurable option that would let programmer decides after how many iterations per frames are allowed for each (or every) loop in a script, and that would break the script and open the debugger.
In most cases, loops doing millions of iterations per frame in a single script attached to a scene node means there is a bug.
And for special cases where these millions iterations are intentional, there could be a set_iterations_watchdog(false) method to disable, a special header keyword added at beginning of the script (like the tool keyword) or a flag that could be added at the end of a loop :
while i < OMEGA safe :
    do_your_stuff()

for i in range(0,999999999999) safe :
   do_your_stuff()

or even special loop keywords :
longwhile i < OMEGA :
    do_your_stuff()

longfor i in range(0,999999999999) :
   do_your_stuff()

it can be done, but there won't be changes to debugger util 1.2

Or instead of solving the Halting Problem, it could be a user-triggered shortcut, because we usually know when an infinite loop occurs (freeze). In Unity3D there is even an AssetStore plugin that does the trick very nicely. It suspends scripts and the editor execution resumes.

@reduz You mentioned this could be done for 1.2 back then. Given how development went I think the debugger improvements are happening right now (for 2.1), so this issue should probably be looked at again.

Not critical for the upcoming 2.1, so moving to the next milestone.

Maybe for 4.0. Seems critical.

I feel like this is not an issue and there isn't really any benefit to get from it.
It's not like this is a real issue that people have to deal with all the time. When there is an infinite loop the developer will notice it quickly.
Also I haven't seen a single intepreter/language ever do this. (Though anything general purpose will suffer the Halting problem mentioned above).

Also when such an infinite loop occurs, you should be able to suspend execution and notice where the code goes (eventually seeing a huge call stack)

Aren't infinite loops a potential issue when writing tool scripts?

@Calinou yes, this is where they are a bigger problem. Although, you should also be able to diagnose them with the command line debugger.

you should be able to suspend execution with the debugger pause button, and notice where the code goes (eventually seeing a huge call stack)

I have never used the debugger but I definitively agree.
However, I would be against detection of infinite loop as it would be "hacky" to implement anyway.

Would it be sufficient to terminate execution of a script after a huge amount of method calls on the call stack, for example, a million?

It probably would.

I haven't looked into the halting problem, but I'm pretty sure that it can be solved for a subset of code. for example the following code is an infinite loop:
while 1:
    print("hi")

I'm not sure how it works in relation to gdscript, but if there are interrupts then it wouldn't necessarily be an infinite loop.

Stack overflows are easy to detect past an absurd stack size, but infinite loops are hardly avoidable. At least, unlike Unity, the editor is preserved if that happens in a game (not in a plugin tho). Using the GDScript debugger remains the best way to deal with them.
A way to hint their detection is to measure how long a non-yielding function takes to execute. If it exceeds 30 seconds then we can very likely hint something went wrong. But even then, that would disrupt cases like benchmarking or tools that genuinely take a lot of time to execute. And you still have threads unadressed.

But even then, that would disrupt cases like benchmarking or tools that genuinely take a lot of time to execute. And you still have threads unadressed.

just add a function or a keyword that disables the "infinite loop" detection when long time execution is intentional.

Closed since the proposal (https://github.com/godotengine/godot-proposals/issues/701) is already exist.

authors: Anutrix Calinou Chaosus NilsIrl SuperUserNameMan UsernameIsAReservedWord Zireael07 Zylann aaronfranke akien-mga philiplb reduz


text:
Compile Visual Scripts to readable Code

That's an unreal blueprint feature my design colleagues are quite hyped about since their prototyping can be useful for the final product and further edited by the coders (that's at least what I've heard).
Will Godot contain such a feature with their visual scripts?
https://www.reddit.com/r/godot/comments/9wozyg/compile_visual_scripts_to_readable_code/

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

authors: clayjohn karotofel


text:
Invalid write and  Condition ' alloc->lock > 0 ' is true. returned: ERR_LOCKED and crash after exit when changing Pinned Points in SoftBody

Godot version:
3.2.dev.custom_build. 3ea33c0e4
OS/device including version:
Ubuntu 19.04
Issue description:
Changing pinned points in Softbody cause showing this error and sometimes corruption of memory crash editor.
 ./core/pool_vector.h:545 - Condition ' alloc->lock > 0 ' is true. returned: ERR_LOCKED

==28562==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900171e6b0 at pc 0x000003c10bc2 bp 0x7fffb4de21a0 sp 0x7fffb4de2190
WRITE of size 4 at 0x61900171e6b0 thread T0
    #0 0x3c10bc1 in btSoftBody::setMass(int, float) thirdparty/bullet/BulletSoftBody/btSoftBody.cpp:689
    #1 0x2b66d1a in SoftBodyBullet::set_node_mass(int, float) modules/bullet/soft_body_bullet.cpp:206
    #2 0x2a4ba51 in BulletPhysicsServer::soft_body_pin_point(RID, int, bool) modules/bullet/bullet_physics_server.cpp:1173
    #3 0xa695542 in SoftBody::_pin_point_on_physics_server(int, bool) scene/3d/soft_body.cpp:743
    #4 0xa6911af in SoftBody::pin_point(int, bool, NodePath const&) scene/3d/soft_body.cpp:672
    #5 0xa676879 in SoftBody::_set_property_pinned_points_indices(Array const&) scene/3d/soft_body.cpp:205
    #6 0xa672e5c in SoftBody::_set(StringName const&, Variant const&) scene/3d/soft_body.cpp:128
    #7 0xa69b80a in SoftBody::_setv(StringName const&, Variant const&) scene/3d/soft_body.h:67
    #8 0xe094e68 in Object::set(StringName const&, Variant const&, bool*) core/object.cpp:446
    #9 0xe2a5462 in UndoRedo::_process_operation_list(List<UndoRedo::Operation, DefaultAllocator>::Element*) core/undo_redo.cpp:311
    #10 0xe2a6998 in UndoRedo::redo() core/undo_redo.cpp:337
    #11 0xe2a31e8 in UndoRedo::commit_action() core/undo_redo.cpp:259
    #12 0x59fb946 in EditorInspector::_edit_set(String const&, Variant const&, bool, String const&) editor/editor_inspector.cpp:2026
    #13 0x59fd355 in EditorInspector::_property_changed(String const&, Variant const&, String const&, bool) editor/editor_inspector.cpp:2043
    #14 0x5a75209 in MethodBind4<String const&, Variant const&, String const&, bool>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:3115
    #15 0xe0a4666 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:933
    #16 0xe0add12 in Object::emit_signal(StringName const&, Variant const**, int) core/object.cpp:1233
    #17 0x598eb39 in EditorProperty::emit_changed(StringName const&, Variant const&, StringName const&, bool) editor/editor_inspector.cpp:88
    #18 0x5f13a1f in EditorPropertyArray::_property_changed(String const&, Variant, String const&, bool) editor/editor_properties_array_dict.cpp:174
    #19 0x5f63478 in MethodBind4<String const&, Variant, String const&, bool>::call(Object*, Variant const**, int, Variant::CallError&) (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x5f63478)
    #20 0xe0a4666 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:933
    #21 0xe0add12 in Object::emit_signal(StringName const&, Variant const**, int) core/object.cpp:1233
    #22 0x598eb39 in EditorProperty::emit_changed(StringName const&, Variant const&, StringName const&, bool) editor/editor_inspector.cpp:88
    #23 0x5dd8c88 in EditorPropertyInteger::_value_changed(double) editor/editor_properties.cpp:822
    #24 0x5a5eace in MethodBind1<double>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:775
    #25 0xe0a4666 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:933
    #26 0xe0add12 in Object::emit_signal(StringName const&, Variant const**, int) core/object.cpp:1233
    #27 0xe0afa7a in Object::emit_signal(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) core/object.cpp:1289
    #28 0x98df578 in Range::_value_changed_notify() scene/gui/range.cpp:49
    #29 0x98dfdbd in Range::Shared::emit_value_changed() scene/gui/range.cpp:60
    #30 0x98e23a6 in Range::set_value(double) scene/gui/range.cpp:100
    #31 0x606734a in EditorSpinSlider::_gui_input(Ref<InputEvent> const&) editor/editor_spin_slider.cpp:109
    #32 0x215a905 in MethodBind1<Ref<InputEvent> const&>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:775
    #33 0xe09fef3 in Object::call_multilevel(StringName const&, Variant const**, int) core/object.cpp:772
    #34 0xe0a3092 in Object::call_multilevel(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) core/object.cpp:873
    #35 0x91742f9 in Viewport::_gui_call_input(Control*, Ref<InputEvent> const&) scene/main/viewport.cpp:1524
    #36 0x918c9a7 in Viewport::_gui_input_event(Ref<InputEvent>) scene/main/viewport.cpp:2114
    #37 0x91a6887 in Viewport::input(Ref<InputEvent> const&) scene/main/viewport.cpp:2672
    #38 0x9168fba in Viewport::_vp_input(Ref<InputEvent> const&) scene/main/viewport.cpp:1302
    #39 0x215a905 in MethodBind1<Ref<InputEvent> const&>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:775
    #40 0xe0a4666 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:933
    #41 0xe0a2ae6 in Object::call(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) core/object.cpp:857
    #42 0x905cd77 in SceneTree::call_group_flags(unsigned int, StringName const&, StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) scene/main/scene_tree.cpp:263
    #43 0x906227f in SceneTree::input_event(Ref<InputEvent> const&) scene/main/scene_tree.cpp:418
    #44 0x14900b0 in InputDefault::_parse_input_event_impl(Ref<InputEvent> const&, bool) main/input_default.cpp:442
    #45 0x1485502 in InputDefault::parse_input_event(Ref<InputEvent> const&) main/input_default.cpp:259
    #46 0x149850a in InputDefault::flush_accumulated_events() main/input_default.cpp:674
    #47 0x141b124 in OS_X11::process_xevents() platform/x11/os_x11.cpp:2612
    #48 0x142dbc0 in OS_X11::run() platform/x11/os_x11.cpp:3174
    #49 0x13aab93 in main platform/x11/godot_x11.cpp:56
    #50 0x7fe905856b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)
    #51 0x13aa799 in _start (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x13aa799)

0x61900171e6b0 is located 89 bytes to the right of 983-byte region [0x61900171e280,0x61900171e657)
allocated by thread T0 here:
    #0 0x7fe907152448 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
    #1 0x2a2129c in btAllocDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:26
    #2 0x2a2130c in btAlignedAllocDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:66
    #3 0x2a21531 in btAlignedAllocInternal(unsigned long, int) thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:247
    #4 0x3ceb261 in btAlignedAllocator<btSoftBody::Node, 16u>::allocate(int, btSoftBody::Node const**) (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x3ceb261)
    #5 0x3ce1956 in btAlignedObjectArray<btSoftBody::Node>::allocate(int) (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x3ce1956)
    #6 0x3cd279b in btAlignedObjectArray<btSoftBody::Node>::reserve(int) thirdparty/bullet/LinearMath/btAlignedObjectArray.h:284
    #7 0x3cd13a3 in btAlignedObjectArray<btSoftBody::Node>::resize(int, btSoftBody::Node const&) (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x3cd13a3)
    #8 0x3bf2661 in btSoftBody::btSoftBody(btSoftBodyWorldInfo*, int, btVector3 const*, float const*) thirdparty/bullet/BulletSoftBody/btSoftBody.cpp:40
    #9 0x3d145ed in btSoftBodyHelpers::CreateFromTriMesh(btSoftBodyWorldInfo&, float const*, int const*, int, bool) thirdparty/bullet/BulletSoftBody/btSoftBodyHelpers.cpp:1054
    #10 0x2b70151 in SoftBodyBullet::set_trimesh_body_shape(PoolVector<int>, PoolVector<Vector3>) modules/bullet/soft_body_bullet.cpp:394
    #11 0x2b643ee in SoftBodyBullet::set_soft_mesh(Ref<Mesh> const&) modules/bullet/soft_body_bullet.cpp:133
    #12 0x2a4234c in BulletPhysicsServer::soft_body_set_mesh(RID, Ref<Reference> const&) modules/bullet/bullet_physics_server.cpp:930
    #13 0xa686aa0 in SoftBody::update_physics_server() scene/3d/soft_body.cpp:448
    #14 0xa6787bd in SoftBody::_changed_callback(Object*, char const*) scene/3d/soft_body.cpp:250
    #15 0x17578f9 in Object::_change_notify(char const*) core/object.h:580
    #16 0x8f66f3a in Node::set_process(bool) scene/main/node.cpp:807
    #17 0x8f4eaae in Node::_notification(int) scene/main/node.cpp:142
    #18 0x16ae481 in Node::_notificationv(int, bool) scene/main/node.h:46
    #19 0x16dda13 in Spatial::_notificationv(int, bool) scene/3d/spatial.h:58
    #20 0x16e01d3 in VisualInstance::_notificationv(int, bool) scene/3d/visual_instance.h:43
    #21 0x16e2993 in GeometryInstance::_notificationv(int, bool) scene/3d/visual_instance.h:87
    #22 0xa2d2a39 in MeshInstance::_notificationv(int, bool) scene/3d/mesh_instance.h:42
    #23 0xa69ca9b in SoftBody::_notificationv(int, bool) scene/3d/soft_body.h:67
    #24 0xe0a4bd1 in Object::notification(int, bool) core/object.cpp:943
    #25 0x8f510fb in Node::_propagate_ready() scene/main/node.cpp:196
    #26 0x8f50952 in Node::_propagate_ready() scene/main/node.cpp:188
    #27 0x8f9fb7a in Node::_set_tree(SceneTree*) scene/main/node.cpp:2534
    #28 0x8f72fab in Node::_add_child_nocheck(Node*, StringName const&) scene/main/node.cpp:1151
    #29 0x8f74b88 in Node::add_child(Node*, bool) scene/main/node.cpp:1170

SUMMARY: AddressSanitizer: heap-buffer-overflow thirdparty/bullet/BulletSoftBody/btSoftBody.cpp:689 in btSoftBody::setMass(int, float)

Steps to reproduce:

In 3.2.3 the error is different, but everything else seems fine (no crash etc). Should be fine to close.

authors: KoBeWi qarmin


text:
InputEventMouseMotion speed is zero when capturing mouse

Godot version:
3.1.1.stable
OS/device including version:
Linux. Solus 4
Issue description:
When using Input.set_mouse_mode(Input.MOUSE_MODE_CAPTURED) mouse speed tends to zero. This worked as expected in Godot 3.0.6
Steps to reproduce:

Run minimal project and observe the console log.
Comment the line Input.set_mouse_mode(Input.MOUSE_MODE_CAPTURED)
Observe console log.

Minimal reproduction project:
capture_mouse_speed.zip

This isn't a bug, in captured mode the cursor must be locked at the center of the viewport (otherwise, other issues will happens), so it's not possible to calculate the speed because the speed is calculated based on last position. Use event.relative instead.
https://docs.godotengine.org/en/latest/tutorials/inputs/mouse_and_input_coordinates.html#hardware-display-coordinates

Pardon the insistence, but why was this working on previous versions?

Because the captured mode was broken for Linux. If you do the same test on Windows with the previous version, it probably won't work.

see here: https://github.com/godotengine/godot/pull/21753

Thanks for the clarification

authors: Juankz guilhermefelipecgs


text:
Vulkan: Alpha channel not included in Viewport capture due to SCREEN_TEXTURE and DEPTH_TEXTURE not being updated

Godot version: Vulkan
OS/device including version: Linux/Arch/Manajro
Issue description: I have a ViewportContainer with a Viewport child to render something in the viewport. I have a custom ShaderMaterial applied to the ViewportContainer
with some code like this:
shader_type canvas_item;

uniform float width: hint_range(0.0, 10.0);
//uniform vec4 color: hint_color;

void fragment() {
	vec4 c = texture(TEXTURE, SCREEN_UV, 0.0);
        COLOR=c.aaaa;
}

the texture always comes out white.
what I am rendering in the viewport is a mesh with a material that is like so:

so that it draws in the alpha channel.
this worked fine when in the godot 3.2 branch and seems to have broken when I try it in Vulkan branch,

in fact any work I have tried to do with capture textures has not worked well.

This issue is still relevant as of 7a31baf3b9dc066fb15af8aa4f90193df3615226. After experimenting with spatial materials, it appears that SCREEN_TEXTURE and DEPTH_TEXTURE are not being updated with the new Vulkan renderer, resulting in texture calls returning a default value. @Calinou Maybe this issue should be renamed and possibly labeled as a regression?

This issue still exists.
Shader which does work correctly in Godot 3.2.3 does not capture SCREEN_TEXTURE in Godot 4 dev 94e5f66cbb399ffd3e501a237d7eb3de79ce1607

This appears to be fixed as of 4.0.rc2, closing.

Testing project: test_shader_viewport.zip
(UV is used instead of SCREEN_UV for sampling, but it that's purely for cosmetic reasons.)

authors: Calinou briansemrau flakusha supagu


text:
[Bullet] 3d physics stepping is two frames late for bullet physics

Godot version:
3.2.1-stable
OS/device including version:
Mac
Issue description:
3d physics stepping is two frames late using bullet physics. Expected would be that it is one frame late.
Steps to reproduce:
Apply either velocity or force to a 3d rigid body. You will notice that the object moves two frames after you apply the velocity.
Minimal reproduction project:
Create a 3d scene and add rigid body with this script.
extends RigidBody

var frame = 0

func _ready():
	pass # Replace with function body.

func _physics_process(delta):
	match frame:
		10:
			linear_velocity = Vector3(1,0,0)
		12:
			linear_velocity = Vector3(0,0,0)

	force_update_transform()
	print("frame: " + str(frame) + " vel " + str(linear_velocity) +" " + str(transform.origin))

	frame += 1

The output is
frame: 9 vel (0, 0, 0) (0, 0, 0)
frame: 10 vel (1, 0, 0) (0, 0, 0)
frame: 11 vel (1, 0, 0) (0, 0, 0)
frame: 12 vel (0, 0, 0) (0.1, 0, 0)
frame: 13 vel (0, 0, 0) (0.2, 0, 0)
frame: 14 vel (0, 0, 0) (0.2, 0, 0)

Expected would be that body has moved at frame 11.
** Note **
Using godot physics is the update is only one frame late. Hence bullet physics works differently.
Create equivalent script for 2d. You will notice that the body moves on frame 11. Hence, 2d physics works correctly.

cc @AndreaCatania

@huhund Does this occur if you use _integrate_forces(state) instead of _physics_process(delta)? This is generally recommended to decrease RigidBody latency by one frame.

Thanks Calinou for looking into this.

No, _integrate_forces doesn't apply velocity correctly. Same issue persist also if apply impulse instead of setting velocity.

The only case that works correctly is applied 2d-physics using _physics_process.
So a new bug actually surfaced: using 2d and _integrate_forces the physics is one frame late

Also, update order is different between Bullet 3D and Godot 2D physics

bullet 3d is

_physics_process
_integrate_forces
_process
( _process ... )

while godot 2d is

_physics_process
_process
( _process ... )
_integrate_forces

I added a test project to github:  https://github.com/huhund/godot_tests.git
Where the 4 uses cases are implemented

Godot 2D single threaded physics, setting velocity in _physics_process

position is applied as expected :)

Godot 2D single threaded physics, setting velocity in _integrate_forces

position is applied one frame late :(

Bullet 3D, setting velocity in _physics process

position is applied one frame late :(

Bullet 3D, setting velocity in _integrate_forces

position is applied one frame late :(

I tried to figure this out on my own. Thankfully the source code of Godot is very well structured and easy to read - big thanks for that.
Anyway, the situation looks like this to me:

Bullet library does not return the most resent position until the pre-tick in the next frame. This sound a bit weird to me but after a lot of log outputs, this is what it looks like.

Currently the update for bullet looks likes

_physics_process
bullet::stepSimulation
2.1 pre-tick
foreach object
apply xform from prev frame
_integrate_forces
2.2. tick (most recent xform not available)
_process

One might think that a work around would be be to never use _physics_process and only rely on _integrate_forces. However, this would conflict with e.g. the 2D physics works. Also, the _integrate_forces is called right after the xform is applied. We wouldn't be able to trust that other objects in the scene have yet had their xforms synced.

Conclusion -

I would suggest that we change so that _physics_process is called from insde the pre-tick. And split the RigidBody::_direct_state_changed functions so that transforms are applied before any process or integrate functions. Like this:

bullet::stepSimulation
1.1 pre-tick
foreach object
apply xform from prev frame
foreach object
_physics_process
foreach object
_physics_process
_integrate_forces
1.2. tick (most recent xform not available)
_process

Maybe this setup would make it more stable? What do you guys think?
It's not perfect because the rendering will always use transforms that are one frame late. But in case we can't read the most recent transforms from bullet there is not much we can do. At least it is not two frames late.

Big thanks for looking into this.
However, can we keep this bug report open? I can still see the two frame issue for Bullet 3D physics in 3.2.3.RC3.
Currently I can work around the issue just by using Godot 3D physics.

Probably this is not yet back ported?

The 3.2.3.RC3 release log says it should have the #40184 commit. I'm happy to test again later if I had the wrong version.

My understanding is that issues should be closed if they're fixed in master.
#40184 was backported (#40185) but then reverted (with 10544f1cf777), because of regression issues. It will be reapplied with #40788, but it depends on whether #40486 is considered a bug or not.

The 3.2.3.RC3 release log says it should have the #40184 commit.

The release log needs to be updated to reflect the reversion.

I was impacted by this issue too. The main problem for me is raycasting from vehicles moving at high velocity. The raycast ends up picking the vehicle itself. I tried to use the body's direct physics state. I would be happy with this solution, but there is still a one-frame lag. I think one of the frames is the flushing happening at the start of the next frame instead of at the end of the current. But the one from the direct body state seems a deeper issue in the Bullet code.

I was impacted by this issue too. The main problem for me is raycasting from vehicles moving at high velocity. The raycast ends up picking the vehicle itself. I tried to use the body's direct physics state. I would be happy with this solution, but there is still a one-frame lag. I think one of the frames is the flushing happening at the start of the next frame instead of at the end of the current. But the one from the direct body state seems a deeper issue in the Bullet code.

Can you use Godot physics instead? Or do you need a specific feature from Bullet?

I was impacted by this issue too. The main problem for me is raycasting from vehicles moving at high velocity. The raycast ends up picking the vehicle itself. I tried to use the body's direct physics state. I would be happy with this solution, but there is still a one-frame lag. I think one of the frames is the flushing happening at the start of the next frame instead of at the end of the current. But the one from the direct body state seems a deeper issue in the Bullet code.

Can you use Godot physics instead? Or do you need a specific feature from Bullet?

No, but I have patched my build for the moment. The original poster is experiencing a one-frame lag, not two. I was experiencing two because I was tinkering with the source code and introducing an extra lag frame.
The reason I was doing that was to expose the bullet's substeps parameter. I might create a proposal and if accepted I might just create a PR from my patch.

authors: AndreaCatania Calinou huhund m4nu3lf madmiraal


text:
Error message trying to save a scene with base node as root

Godot version: Godot Engine v3.2.1.stable.official
OS/device including version: Windows 10, version 2004
Issue description: Not really a major issue, but whenever I try to save a scene whose root node is a base node, as opposed to a node2d or node3d, I get an error message in the console, saying it was unable to create a PNG image

Steps to reproduce: Create a new scene. In Create Root Node, select Other Node->Node and simply save this scene. The message will show up in the output console
Minimal reproduction project: A project consisting of a single root node scene

same error with #36456
I guess this happens when editor can't create a thumbnail for the current open scene.

To reproduce the issue a scene must contain no visual nodes and "3D Editor" feature must be disabled. If this feature is enabled, preview is generated without errors. A restart of the editor is required after the change in features. Still happens in 3.2.2-beta3 precompiled and with 3.2 branch.
In master branch I can't get this error the same way, but as soon as you disable "3D Editor" feature another issue starts popping: "Cannot get class 'StreamTexture'." This may or may not obscure the original issue in this case, I can't really tell. However, there had been many changes in related classes, so maybe it was indeed fixed as a side effect of one of them.

authors: Joakker pycbouh volzhs