Fixes empty segments creation in tsdb when presence of a very old block

Signed-off-by: Harkishen Singh<EMAIL_ADDRESS>
Fixes: #6359
Fixes empty segments creation when the most recent block is old. If no walls found, the minTime is shifted to the maxTime of the last block.

cc @brian-brazil @codesome @krasi-georgiev

@brian-brazil done!

This would have us read the WAL twice at startup, which isn't desirable. The head rather than the db should also be dealing with WAL-level stuff.

@brian-brazil I hope the recent changes pushed is what we want.
@codesome, for the case involving no wal but a very old block, should we set the h.minValidTime to current timestamp?

That looks better alright.

for the case involving no wal but a very old block, should we set the h.minValidTime to current timestamp?

Could we fallback to whatever logic we use when there's no data at all?

@codesome, for the case involving no wal but a very old block, should we set the h.minValidTime to current timestamp?

I think to the maxt of the last block on disk.

How do we decided when to call a block very old. Like beyond a particular time range?
Basically what I get through this discussion is that we simply consider the first sample. But, if wal is empty, take the maxt of last block. However, the later part will again cause lots of empty segments.
@krasi-georgiev @brian-brazil

yeah I am not sure, I guess need to dig in the code and make a list of all cases.
NO WAL NO blocks.
NO WAL with blocks
With WAL and NO blocks
With WAL and with blocks

We'd need to handle this at the compaction stage rather than the WAL reading stage to do that.
It also occurs to me that setting min valid time like this is incorrect, as it prevents ingesting data that is older than the oldest sample in the WAL. Not that that should be common, but it's not something we should break.

@brian-brazil you probably have the most context here so can you sum up how should the head min/maxt be set then?
Maybe a good start would be to remind us what was the accepted time range in the past that samples are accepted. For example if current timestamp is 10000 how much in the past would tsdb accept samples?

1-3 hours, depending on where you are in the compaction cycle.
I suspect this is something we need to handle at the compaction stage.

@codesome as far as I remember, there was some other PR which covered this PR's purpose as well. Right?

That should be https://github.com/prometheus/prometheus/pull/7579

We have looked at it in the bug scrub and decided to close this as superseded by  #7579


Create API service for MVP

Description
We need to be able to retrieve data from an external resource. This should (probably) be handled by an API service that is injected in the service setup.
Take a look at the current setup, and try to understand how AddSingleton and AddScoped works.
Preferably document this in the Wiki as well, as this serves as the foundation for the DI (Dependency Injection).
Subtasks

[x] Assign project, milestone, labels and assignees
[ ] Create API service
[ ] Add API service to DI chain (services)

Related sources

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-5.0
Partially blocked by #16 (we should only type the response type once)
Blocked by #15

Figured out how to do this, currently working on POC.
How about a quick sync tomorrow, @IT2901-SINTEF01/backend?


Use master jenkins shared pipeline

Updated the public library to master

@ameenhaq in future it might be worth considering a rebase to bring the latest changes into a PR. It makes for a much cleaner history.
I'm going to fixup this branch so its organised.


Publish v4 to JSR

Motivation
I'm going to start migrating dependent projects to<EMAIL_ADDRESS>so I'd like to have v4 available on JSr.
Approach
Cherry-picked commits from v3

These are JSR-specific rules mostly to avoid slow types.


Strange error. Any way to fix this ?

Bot_131: Packet error detected for packet: 10 00 00 69 46 10 00 53 f0 ff ff 9d 14 00 00 4d 00 a5 07 ff 00 00 00 02 4e 10 00 e7 ef ff ff 8d 13 00 00 2d 00 a5 07 ff 00 00 00 7f 4e 10 00 a9 ef ff ff 34 13 00 00 3e 00 a5 07 ff 00 00 00 f8 f8 4e 10 00 00 f6 ff ff 95 15 00 00 46 00 07 96 ff 00 00 00 34 51 10 00 da f5 ff ff 44 12 00 00 21 00 ed ff 07 00 00 00 00 00 00 00 00 00 00
C:\Users...\node_modules\ws\lib\WebSocket.js:426
event.type = 'error';
^
TypeError: Cannot assign to read only property 'type' of continuation frame cannot follow current opcode
at WebSocket.onError (C:\Users...\node_modules\ws\lib\WebSocket.js:426:16)
at emitTwo (events.js:87:13)
at WebSocket.emit (events.js:172:7)
at Receiver.onerror (C:\Users...\node_modules\ws\lib\WebSocket.js:851:10)
at Receiver.error (C:\Users...\node_modules\ws\lib\Receiver.js:321:8)
at Receiver.processPacket (C:\Users...\node_modules\ws\lib\Receiver.js:212:12)
at Receiver.add (C:\Users...\node_modules\ws\lib\Receiver.js:95:24)
at Socket.realHandler (C:\Users...\node_modules\ws\lib\WebSocket.js:800:20)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)

@picusc You need to update to latest version, it's fixed already

try to reinstall
npm install


WARNING: A connection to https://... was leaked. Did you forget to close a response body?

Version:
com.squareup.okhttp3:okhttp:3.0.1
Log message:
<timestamp> okhttp3.ConnectionPool pruneAndGetAllocationCount
WARNING: A connection to https://... was leaked. Did you forget to close a response body?

Code:
private String get(final String url) {
    String res = null;
    try {
        final Request req = new Request.Builder().url(url).get().build();
        final Response resp = ok.newCall(req).execute();
        final int code = resp.code();
        if (code == 200) {
            final ResponseBody body = resp.body();
            res = body.string();
            body.close(); // even this doesn't work!
        }
    }
    catch (final Throwable th) {
        System.out.println(th.getMessage());
    }
    return res;
}

That code does not close the body when the code is not 200. Use a try/finally with body.close() in the finally block.

If the code is not 200 -> there's no call to resp.body() -> there's no body -> there's nothing to close. Is it so?
I thought I don't have to call body.close() at all! I just put it there for an experiment. Do I have to call body.close() everytime?

Everytime.

Ok, it's called eveytime, as you see in my code. But I still get that warning.

I get that warning from time to time. I make like 100 calls and get 1 warning. 99 calls are ok.

Code is the same in all 100 calls.

Your code calls it only in the success case, which is not every time.

If the code is not 200 -> there's no call to resp.body() -> there's no body -> there's nothing to close.

This is false.

I commented each valuable line.
private String get(final String url) {
    String res = null;
    try {
        final Request req = new Request.Builder().url(url).get().build();
        final Response resp = ok.newCall(req).execute();
        final int code = resp.code(); // can be any value
        if (code == 200) {
            final ResponseBody body = resp.body(); // body exists, I have to close it
            res = body.string(); //
            body.close(); // I close it explicitly
        }
        // if code was not 200 -> there's no body (opened to be closed) -> there's nothing to close
        // What am I supposed to close?
    }
    catch (final Throwable th) {
        System.out.println(th.getMessage());
    }
    return res;
}

You have to close the body. Just because you are not calling the method doesn't mean the body is not there.
ResponseBody body = resp.body();
try {
  ...
} finally {
 body.close();
}

Ignoring this fact, the code you showed doesn't cover the case when body.string() throws either.

What about this case:
private String get(final String url) {
String res = null;
try {
final Request req = new Request.Builder().url(url).get().build();
final Response resp = ok.newCall(req).execute();
final int code = resp.code(); // can be any value
System.out.println(code); // I don't want to get body from resp, just print the code
// There's no body, there's nothing opened, there's nothing to close
// Do I have to call resp.body().close() anyway in finally block or something like that?
}
catch (final Throwable th) {
System.out.println(th.getMessage());
}
return res;
}

there's nothing opened

The connection is open. That's where the code came from. You always have to close the body. There's nothing ambiguous about "always".

https://github.com/square/okhttp/issues/2158#issuecomment-167283937
"Most call body().string() which closes it for you."

Calling string() closes the body, yes.

So, just to read the code of the get response, I have to write something like:
private void printCode(final String url) {
	Response resp = null;
	try {
		final Request req = new Request.Builder().url(url).get().build();
		resp = ok.newCall(req).execute();
		final int code = resp.code();
		System.out.println(code);
	}
	catch (final Throwable th) {
		System.out.println(th.getMessage());
	}
	finally {
		if (resp != null) {
			try {
				resp.body().close();
			}
			catch (final Throwable th) {
				System.out.println(th.getMessage());
			}
		}
	}
}

Nope
Request req = new Request.Builder().url(url).build();
Response res = ok.newCall(req).execute();
System.out.println(resp.code());
res.body().close();

The question was answered earlier, so I'm closing the issue.

So this is the right one:
private String get(final String url) {
	String res = null;
	try {
		final Request req = new Request.Builder().url(url).get().build();
		final Response resp = ok.newCall(req).execute();
		final int code = resp.code();
		if (code == 200) {
			try (ResponseBody body = resp.body()) {
				res = body.string();
			}
		}
	}
	catch (final Throwable th) {
		System.out.println(th.getMessage());
	}
	return res;
}

That code doesn't close the body in non-200 cases.

That's a bit weird thing to remember, to close something you didn't explicitly open :)

You opened it by making the request. Calling body just accesses something that already exists.

That's the right (ugly) one:
private String get(final String url) {
	String res = null;
	try {
		final Request req = new Request.Builder().url(url).get().build();
		final Response resp = ok.newCall(req).execute();
		final int code = resp.code();
		try (final ResponseBody body = resp.body()) {
			if (code == 200) {
				res = body.string();
			}
			else {
				log.warn("code: " + code);
			}
		}
	}
	catch (final Throwable th) {
		log.warn(th.getMessage());
	}
	return res;
}

So if I call body.string() and it throws exception, body remains opened and has to be closed, right?

I mean body.string() closes body implicitly only in positive case with no exceptions, and remains it opened if the exception is thrown, right?

I think body.string() automatically closed.
There is like
if (!response.isSuccessful()) throw new IOException("Unexpected code " + response);

so you don't need 200 checks.

@iNoles If that was the case, the first version of the code wouldn't case warnings, I guess.

body.string() which closes body anyway, if there's or there's no exception - that would be a nice cute API :)

The first version doesn't close in the non-200 case.
string() always closes. You can look at the source.
On Wed, Feb 3, 2016, 6:53 PM bxqgit<EMAIL_ADDRESS>wrote:

body.string() which closes body anyway, if there's or there's no exception

that would be a nice cute API :)

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2311#issuecomment-179538063.

@bxqgit
private String get(final String url) {
    String res = null;
    try {
        final Request req = new Request.Builder().url(url).get().build();
        final Response response = ok.newCall(req).execute();
        if (!response.isSuccessful()) {
            log.warn(new IOException("Unexpected code " + response));
        } else {
            res = response.body().string();
        }
    catch (Throwable th) {
        log.warn(th.getMessage());
    }
    return res;
}

@JakeWharton ok, then this should work:
private String get(final String url) {
	String res = null;
	try {
		final Request req = new Request.Builder().url(url).get().build();
		final Response resp = ok.newCall(req).execute();
		res = resp.body().string();
		final int code = resp.code();
		if (code != 200) {
			log.warn("code: " + code);
		}
	}
	catch (final Throwable th) {
		log.warn(th.getMessage());
	}
	return res;
}

@iNoles Nope, same mistake. After "ok.newCall(req).execute();" you already have implicit body, which you have to close.

You just need to close the ResponseBody from your Response, as stated a many times above.
Something like the following:
String get(String url) {
  Request req = new Request.Builder().url(url).get().build();
  try {
    Response resp = ok.newCall(req).execute();
    ResponseBody body = resp.body();
    if (resp.isSuccessful()) {
        return body.string(); // Closes automatically.
    } else {
        body.close();
        return null;
    }
  } catch (IOException e) {
    log.print(e.getMessage());
    return null;
  }
}

How does this works with timeouts? How can I close the response body if I don't have any response body ref to begin with?
private boolean isReachable(Host host, int connectTimeout) {
	boolean reachable = false;

	OkHttpClient client = new OkHttpClient.Builder()
			.connectTimeout(connectTimeout, TimeUnit.MILLISECONDS)
			.readTimeout(connectTimeout, TimeUnit.MILLISECONDS)
			.build();

	try {
		Request request = new Request.Builder()
				.url(host.getCanonicalName())
				.build();

		client.newCall(request).execute().body().close();
		reachable = true;
	} catch (Exception exc) {
		reachable = false;
	}

	return reachable;
}

I keep getting warnings about response

    Response response;
    try {
        Request request = new Request.Builder()
                .url(host.getCanonicalName())
                .build();

        response = client.newCall(request).execute();
        reachable = true;
    } catch (Exception exc) {
        reachable = false;
    } finally {
        if (response != null) response.body().close();
    }

Yeah, you’re right. I’ll try to reproduce.

@JakeWharton I'm using Retrofit2 + okhttp3 in a java application fx, but I'm with the sample Which problem? Most call body (). String () Which closes it for you.
In my project I have a ServiceCreator class to create the retrofit coneções and okhttp, but the call I am not able to make a close in the body, following the examples:
`public class ServiceGenerator {
public static OkHttpClient.Builder httpClient;
public static Retrofit createRetrofit(String token) {
if (httpClient == null){
    httpClient = new OkHttpClient.Builder();
    if (token != null){
        httpClient.addInterceptor(new Interceptor() {
            @Override
            public okhttp3.Response intercept(Interceptor.Chain chain) throws IOException {
                Request original = chain.request();

                Request.Builder requestBuilder = original.newBuilder()
                        .header("Authorization", "Token token=" + token)
                        .method(original.method(), original.body());

                Request request = requestBuilder.build();

                return chain.proceed(request);
            }
        });
    }
    httpClient.connectTimeout(50, TimeUnit.SECONDS);
    httpClient.addInterceptor(addLoggin());

}

OkHttpClient client = httpClient.build();
Retrofit retrofit = new Retrofit.Builder().baseUrl(Constant.BASEURL)
        .addConverterFactory(ScalarsConverterFactory.create())
        .addConverterFactory(GsonConverterFactory.create(new GsonBuilder()
                .excludeFieldsWithModifiers(Modifier.FINAL, Modifier.TRANSIENT, Modifier.STATIC).create())).client(client).build();

return retrofit;

}
public static  S createService(String token, Class serviceClass) {
return createRetrofit(token).create(serviceClass);
}
private static HttpLoggingInterceptor addLoggin(){
HttpLoggingInterceptor logging = new HttpLoggingInterceptor();

logging.setLevel(HttpLoggingInterceptor.Level.NONE);
return logging;

}
}`
Usage into a ScheduleServe to polling:
`CatalogListener catalogListener = ServiceGenerator.createService(token, CatalogListener.class);
Call<List<Category>> call = catalogListener.syncMerchantId(merchantId);

call.enqueue(new Callback<List<Category>>() {

    @Override
    public void onResponse(Call<List<Category>> call, retrofit2.Response<List<Category>> response) {

// System.out.println(response.body());
cb.onResponse(response.body());
}
    @Override
    public void onFailure(Call<List<Category>> call, Throwable t) {
        System.out.println(t);
        cb.onFailure(t);
    }
});`

@JakeWharton Is it guaranteed, that Response.body() is always != null? Javadoc is unfortunately silent about it.

A variation on the last example the @swankjesse posted is to use java.util.Optional (Java 8) to outsource the null-assertion conditional, like so:
Response response = null;
try {
    // ...
} catch (Exception e) {
    // ...
} finally {
    Optional.ofNullable(response).ifPresent((res) -> res.body().close());
}

...though another difference is that response needs to be initialized to null (rather than simply declared and not initialized), or else there's a compile error.

I do have to say, this whole thing makes for a pretty weird api

This really is kind of a strange design. Are there plans to change this behaviour eventually?

This is what your calling code should look like.
    Request request = new Request.Builder()
        .url("https://publicobject.com/helloworld.txt")
        .build();

    try (Response response = client.newCall(request).execute()) {
      if (!response.isSuccessful()) throw new IOException("Unexpected code " + response);

      Headers responseHeaders = response.headers();
      for (int i = 0; i < responseHeaders.size(); i++) {
        System.out.println(responseHeaders.name(i) + ": " + responseHeaders.value(i));
      }

      System.out.println(response.body().string());
    }

I wouldn't call this code/API beautiful.

In Android (API 26), you don't open any "body" explicitly. Every time I get a response code 301 or 302 for a page, then after opening another page I get the error "Did you forget to close a response body". This doesn't happen for 404s. So there must be an error in the okhttp implementation in the Android API.
Example: Just run testpage() in the MainAcitivity's onCreate.
`package com.testhttp.whatever;
import android.util.Log;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
public class test {
private static String getpage(String Url) {
    StringBuilder pageContent = new StringBuilder();
    int responseCode=0;
    try {
        URL httpUrl = new URL(Url);

        HttpURLConnection conn = (HttpURLConnection) httpUrl.openConnection();
        if (conn!=null) {
            conn.setConnectTimeout(5000);
            conn.setReadTimeout(5000);
            responseCode = conn.getResponseCode();
            if (responseCode != 200) throw new IllegalAccessException(" http connection failed");

            BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream()));
            String line;
            while ((line = br.readLine()) != null) pageContent.append(line);
            conn.disconnect(); //doesn't help
        }
    } catch (IOException e) {
        e.printStackTrace(); //this catches timeouts
    }
    catch (IllegalAccessException e) {
        Log.d("test","responsecode="+responseCode);
        e.printStackTrace(); //this catches responsecode != 200
    }

    return pageContent.toString();
}

static void testpage() {
    new Thread() {
        public void run() {
            Log.d("test",getpage("http://topsy.one/"));
            Log.d("test",getpage("https://google.com/"));
        }
    }.start();
}

}
`

@mb040574 you are not closing BufferedReader.
BufferedReader br = null;
try {
        URL httpUrl = new URL(Url);

        HttpURLConnection conn = (HttpURLConnection) httpUrl.openConnection();
        if (conn!=null) {
            conn.setConnectTimeout(5000);
            conn.setReadTimeout(5000);
            responseCode = conn.getResponseCode();
            if (responseCode != 200) throw new IllegalAccessException(" http connection failed");

            br = new BufferedReader(new InputStreamReader(conn.getInputStream()));
            String line;
            while ((line = br.readLine()) != null) pageContent.append(line);
        }
    } catch (IOException e) {
        e.printStackTrace(); //this catches timeouts
    }
    catch (IllegalAccessException e) {
        Log.d("test","responsecode="+responseCode);
        e.printStackTrace(); //this catches responsecode != 200
    } finally {
      if (br != null) {
          br.close();
    }
}
return pageContent.toString();

The code never gets down to the BufferedReader in case of response code 301/302, and I have tried that. It doesn't help.
while ((line = br.readLine()) != null) pageContent.append(line);
br.close();

@mb040574
HttpURLConnection is an abstract class, if you debug what is actual implementation it is usually:
com.android.okhttp.internal.huc.HttpURLConnectionImpl
and if you look at the implementation of disconnect() method you will find the answer:
// This doesn't close the stream because doing so would require all stream
// access to be synchronized. It's expected that the thread using the
// connection will close its streams directly. If it doesn't, the worst
// case is that the GzipSource's Inflater won't be released until it's
// finalized. (This logs a warning on Android.)

Well, the funny thing is that on the 64bit emulator this issue does not occur.

Calling string() closes the body, yes.

damn if I only new this 2 hours ago.  i did a null check before using response.body().string() and each time i was trying to use it the response was closed.
So thank you for this. I think it would have taken me another couple of hours before i could figure it out

How to close body when you are using Okhttp with volley?.
class OkHttpStack extends HurlStack {

    private final OkUrlFactory okUrlFactory;

    OkHttpStack() {
        this(new OkUrlFactory(new OkHttpClient()));
    }

    private OkHttpStack(OkUrlFactory okUrlFactory) {
        if (okUrlFactory == null) {
            throw new NullPointerException("Client must not be null.");
        }
        this.okUrlFactory = okUrlFactory;
    }

    @Override
    protected HttpURLConnection createConnection(URL url) throws IOException {
        return okUrlFactory.open(url);
    }

}

synchronized RequestQueue getRequestQueue() {
        if (mRequestQueue == null) {
            mRequestQueue = Volley.newRequestQueue(mContext,new OkHttpStack());
        }
        return mRequestQueue;
    }

I might have the answer for the problem at begining of this thread
(I read the firsts posts were the guy talks about having 99 normal connection and 1 with problem and other people say that should close in case code != 200, but i didn't read the whole thread is it got super long)
I'm using okhttp with retrofit in my API, this API is stable and i've working with it for 2 years already...
I started a new app using my api and everything was Ok, but then i needed to test something very quickly in the app so I decided to use
try {
            URLConnection conn = new URL(somesite).openConnection();
            conn.connect();
            //((HttpURLConnection) conn).disconnect();
            return true;
        } catch (Exception e) {
            return false;
        }

after this I start getting
W/OkHttpClient: A connection to http://... was leaked. Did you forget to close a response body?
Well that is true, I didn't close the response body, but I was not using okhttp for that. I still dont know how okhttp got resource leak from my URLConnection but that was the reason.
So I decided to share to let other people with similar problem may check this posibility

@bolds07 Android uses OkHttp internally as of Android 4.4 which I think causes the warning.

@jemaystermind  So does Retrofit 2.x automatically close response bodies for us or do we have to do it ourselves?

My approach if i want to just fetch the status code of the response
Request req = new Request.Builder().url(url).build();
try(Response res = ok.newCall(req).execute()) {
   System.out.println(resp.code());
}

This uses java 7's auto closable feature
If you look into the implementation of the close() method in Response class you can see that it in turn calls the close() method of response body. Below is the actual code for easy reference.
public void close() {
    if (this.body == null) {
        throw new IllegalStateException("response is not eligible for a body and must not be closed");
    } else {
        this.body.close();
    }
}

@jemaystermind, on android even when I use disconnect i'm getting this warning... do you know what can i do in order to stop it?

Same here, I'm not even using OkHttp, and in my code I close the connection:
private int pushToRemote() {
        JSONArray jsonArray = new JSONArray(pendingUploads.values());
        HttpURLConnection conn = null;
        int responseCode = UPLOAD_FAILED;
        try {
            URL address = new URL(url);
            conn = (HttpURLConnection) address.openConnection();
            conn.setReadTimeout(TIMEOUT);
            conn.setConnectTimeout(TIMEOUT);
            conn.setRequestProperty("Content-Type", "application/json");
            conn.setRequestMethod(POST);
            conn.setDoInput(true);
            conn.setDoOutput(true);
            OutputStream output = conn.getOutputStream();
            OutputStreamWriter writer = new OutputStreamWriter(output, Charset.forName("UTF-8"));
            writer.write(jsonArray.toString());
            writer.flush();
            writer.close();
            output.close();
            responseCode = conn.getResponseCode();
        } catch (IOException e) {
            //not using Loggy as the worker may run when Loggy not initialized
            Log.e(UploadLogsWorker.class.getName(), "Error uploading to server " + e.getMessage());
        } finally {
            if (conn != null) {
                conn.disconnect();
            }
        }
        return responseCode;
    }

Yet, when I'm running a Instrumented test I see this line:
2018-12-12 11:44:27.898 25514-26209/******.test W/OkHttpClient: A connection to http://******:10301/ was leaked. Did you forget to close a response body?

I use try/finally but I still get warn message
`[OkHttp ConnectionPool] WARN  okhttp3.OkHttpClient - A connection to some_site was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE);
`
import okhttp3.OkHttpClient
var оkHttpClient = OkHttpClient()
 val orderBookResponse = оkHttpClient.newCall(requestOrderBook).execute()
        val orderBookResponseBody = orderBookResponse.body()
        try {
            if (orderBookResponseBody != null) {
                val orderBookResponseBodyString = orderBookResponseBody.string()
                val bodyJsonElement = parser.parse(orderBookResponseBodyString)
            }
        } finally {
            if (orderBookResponseBody != null) {
                orderBookResponseBody.close()
            }
        }

Just saw this in my logs from Firebase Crashlytics init.  Hopefully relevant / authoritative:

It looks like it was decided this was a platform issue, rather than anything at the app level. As a result, the logged warning was removed from the platform in https://android-review.googlesource.com/c/platform/external/okhttp/+/460418.

I am so glad can the comments from author.  In my case I am useing Response rather than ResponseBody,  so how can I close .
package com.heitouyang.promise.server.callback;
import android.content.Intent;
import androidx.annotation.NonNull;
import androidx.localbroadcastmanager.content.LocalBroadcastManager;
import com.heitouyang.promise.activity.LoginActivity;
import com.heitouyang.promise.app.ZActivityManager;
import com.heitouyang.promise.app.ZApplication;
import com.heitouyang.promise.retrofit.APIClient;
import com.heitouyang.promise.server.resp.base.RespBody;
import com.heitouyang.promise.util.Logger;
import com.heitouyang.promise.util.ZPreference;
import com.heitouyang.promise.util.ZToast;
import java.net.SocketTimeoutException;
import java.net.UnknownHostException;
import retrofit2.Call;
import retrofit2.Callback;
import retrofit2.Response;
/**

Created by zw.zhang on 2017/8/17.
*/

public abstract class ZCallBackWithFail implements Callback {
/**
* override this method to do some thing after fail.
*/
public boolean fail;
public ZCallBackWithFail() {
}

public abstract void callBack(T response);

@Override
public void onResponse(@NonNull Call<T> call, @NonNull Response<T> response) {
    if ((response.code() != 200) || response.body() == null || (response.body().errcode != 0)) {
        fail = true;
    }
    if (response.code() >= 500) {
        fail = true;
        ZToast.toast("服务器暂时无法为您提供服务，请稍后再试");
    } else if (response.code() == 401) {
        loginOut("你需要重新登录");
        return;
    }

    try {
        if (response.body() != null && response.body().errcode != 0) {
            long errCode = response.body().errcode;
            if (errCode == -10000 || errCode == -10001 || errCode == -10006 || errCode == -10007 || errCode == -1012 || errCode == -1014) {
                String m = "你的账号已在其他设备登录，是否重新登录";
                if (errCode == -10001 || errCode == -10000) {
                    m = "登录过期，需要重新登录";
                } else if (errCode == -1012) {
                    m = "用户不存在";
                }
                loginOut(m);
            } else {
                ZToast.alertDialog(response.body().errmsg);
            }
        }
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        callBack(response.body());
    }
}

private void loginOut(String m) {
    if (ZPreference.isLogin()) {
        APIClient.getInstance().getApiInterface().loginOutNotRxjava().enqueue(new ZCallBackWithFail<RespBody>() {
            @Override
            public void callBack(RespBody response) {

                ZPreference.clear();
                Intent intent = new Intent("android.intent.action.MY_BROADCAST");
                intent.putExtra("msg", "hello receiver.");
                ZApplication.APP.get().sendBroadcast(intent);
                LocalBroadcastManager.getInstance(ZApplication.APP.get()).sendBroadcast(intent);
                ZToast.showLoginOutDialog(m, (dialog) -> ZActivityManager.getInstance().getCurrentActivity().startActivity(new Intent(ZApplication.APP.get(), LoginActivity.class)));
            }
        });
    }
}

@Override
public void onFailure(Call<T> call, Throwable t) {
    t.printStackTrace();
    Logger.e(t.getMessage());
    if (ZApplication.APP != null && ZApplication.APP.get() != null) {
        APIClient.initApiClient();
    }
    fail = true;

    if (t instanceof UnknownHostException || t instanceof SocketTimeoutException) {
        ZToast.toast("网络环境差，请检查网络设置");
    } else {
        ZToast.toast("服务器暂时无法为您提供服务，请稍后再试");
    }

    try {
        callBack(null);
    } catch (Exception e) {
        e.printStackTrace();
    }

}

}

I found "OkHttpClient: A connection to http://test-api.heitouyang.cn/ was leaked. Did you forget to close a response body?" should throw from glide. I do nothing about the glide OkHttpClient. How can I solve this with glide.

It is wired. According to try-with-resources

The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement. Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.

public final class Response implements Closeable {
...

So I think this would work
        try (Response response = postCall(WRITE_LOG, payload)) {
            return true;
        }

because response would be closed by try-with-resources.
However tomcat warns that the connection was leaked.

Fixing this in your code might be as simple as updating
return client.newCall(request).execute().code == 200

to
return client.newCall(request).execute().use {
    it.code == 200
}

we are using response.body().byteStream(), so we will have to manually close the body by calling response.close(); or response.body().close();
on calling  response.close(); , will the framework also terminate Http connection made to external service ?
If yes, then it would lead to conection establishment overhead for every new request.

@JakeWharton @swankjesse


Define standard conformance format for a GatewayClass to communicate what it supports to operators

What would you like to be added:
GatewayClasses encapsulate the capabilities that an implementation of Service APIs supports. However, for the platform operators or application operators who might deploy Gateways in a cluster may not know exactly what within the API a given GatewayClass supports. This issue proposes a standard way for all GatewayClasses to communicate to a user what it supports.
Let's say I have an acme-lb GatewayClass. The GatewayClass should be able to tell me the following:
kind: Gateway
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: supported
spec:
  gatewayClassName: supported
  listeners:
  - protocol:
      http: supported
      tcp: unsupported
      udp: unsupported
    port: supported
    routes:
      kind:
        HTTPRoute: supported
        TCPRoute: unsupported
        UDPRoute: unsupported
      selector:
        matchLabels: supported
...
---
HTTPRoute:
  spec:
    hostnames: supported
    rules:
    - matches:
      - path:
          type:
            prefix: supported
            exact: supported
            regularexpression: unsupported
            implementationspecific: unsupported
        headers:
          type:
            exact: supported
            implementationspecific:
              contains: supported # Will match traffic with any single header that contains this string
              doesnotcontain: supported # Will match traffic if no headers contain this string
...

This is a terrible example of the format but you get the idea :) Perhaps OpenAPI has some kind of capability for this.
The goals this aims to achieve:

Provide a standardized way for all GatewayClasses to communicate which aspects of the API they support.
Core fields must be supported to achieve conformance, but since extended fields can be optional it will be very useful to understand which extended fields are implemented by a given GatewayClass.
Custom fields (like annotations, ImplementationSpecific fields, or CRDs that can be referenced) should also be able to be communicated in some way so operators can understand how a GatewayClass has been extended with additional functionality.
Provide a way for the provider to give additional context to describe implementation-specific aspects of a core, extended, or custom field. The example above with contains illustrates this.

How a GatewayClass provider communicates to the operator what its capabilities are can be done in many different ways:

Perhaps conformance tests spits this out as a standardized output and providers can simply put this in their docs
Perhaps comments or fields within a GatewayClass implementation can fill out these fields. This would give the opportunity for implementors to add special comments and context regarding support for specific fields. This might be the case where a field is supported but how it functions requires more context or explanation.

cc @robscott

/kind documentation

/remove-lifecycle rotten

I think we talked about something like this a long time ago, having this sort of information be passed in the Status of the GatewayClass, so that you can look at a GatewayClass and undestand what features will work, before you start putting Routes into Gateways. It might make sense to have that information in the Gateway status as well though.

/remove-lifecycle stale
/lifecycle frozen

Despite this issue being quite old, we the maintainers are still pretty convinced that we want to have this functionality in a future release. This could be particularly useful for conformance test targeting, as well as generally useful for end-users. We are marking this help wanted as we're looking for contributors with strong use cases to help champion and drive this forward.

While grooming we saw that this one was open for a long period of time without anyone with a strong use case to champion it. We're going to close this as we don't expect anyone's ready to drive it forward, but if you still want this feature and have a strong use case we will be happy to reconsider this and re-open.

tbh this is pretty similar to some of the ideas in #1804

Indeed, for anyone visiting this issue please consider it a duplicate of #1804 and follow up over there :+1:


Create a controllable env for bologna/luxembourg

unlikely to happen soon; punting

re-opening this, since there is some interest on it (see #399)


Deepspeed and bf16-true

In the finetuning scripts, we only allow
precision: Literal["bf16-true", "32-true"] = "bf16-true",

But we also use DeepSpeed when devices > 1. However, in this case, you'd get a
ValueError: `precision='bf16-true')` is not supported in DeepSpeed. `precision` must be one of: ('32-true', '16-mixed', 'bf16-mixed').

Should we allow bf16-mixed, or should we switch to FSDP? Or something else?

We can choose the precision based on whether deepspeed is used. I guess @awaelchli manually changed the precision value when trying out deepspeed in https://github.com/Lightning-AI/lit-llama/pull/128 (where this code originally comes from).
Note that FSDP also wouldn't work with bf16-true.


Updated profile for George Aziz

Updated image and social links

👷 Deploy Preview for hpislab processing.

Name
Link

🔨 Latest commit
f4ede2d961e0bdce7a5abfd34b2a98a68c51ac87

🔍 Latest deploy log
https://app.netlify.com/sites/hpislab/deploys/62bb0de967de970008e4351a


Improve YAML parsing

This PR:

implementes YAML file validation (#636)

$ kontena app deploy
YAML contains the following unsupported options and they were rejected:
kontena.yml:
  db:
    - statefull: ["invalid option"]
base.yml:
  db:
    - user: ["unsupported option"]
YAML validation failed!
kontena.yml:
  web:
    - hooks: {"post_start":{"0":{"cmd":["is missing"]}}}

enables extending services from the same YAML file

web:
  extends:
    service: base

adds support for environment variables substitution (both $VAR and ${VAR} syntax are supported)

web:
  image: myapp:$TAG

refactors code base to make it possible to support docker-compose.yml version 2

Fixes #636

LGTM


Settle on a documentation format

What output formats do we want?
What capabilities do we need in the source format (e.g. in terms of interlinking, other base capabilities, etc.?)

Typst is a document format written in Rust.

@JoelMarcey I think this can maybe be closed?

Yep. We are settling on mdbook with extensions, including those provided by @ehuss


PP-541 Remove old states 'confirmed' and 'captured'.

WHAT
A brief description of the pull request:
PP-541 Remove old states 'confirmed' and 'captured'.
HOW
Steps to test or reproduce:
States have been merged in to 'success'. We allowed this in a previous changeset, but can now remove the old states and with it backwards compatibility with the old code which has now been updated on all our environments.
WHO
Who should review this pull request:

[X] Developers
[ ] WebOps

👍


feat: replace '/api/v1/market' call with '/api/v1/quote' in getUsdRate

This changes the endpoint used in getUsdRate method, because the one currently used has been deprecated.
I tested it in web, checked rates there and performed a swap.
closes https://github.com/shapeshift/lib/issues/759
Steps to test :

Link with web locally
Start swap with ERC20 tokens (not ETH)
Verify rates are consistent with current market
Perform swap

@0xdef1cafe I was finally able to reproduce this issue
This occurs in getCowSwapTradeQuote.ts (where quote api is already used) when CowSwap expects a fee greater than $10 (which is our minimum when lower value is provided by UX / the user).
This is only occurring with quote api when we are performing a sell operation, so the code in this PR where I am performing a buy is not at fault I think.
I have tried changing getCowSwapMinMax.ts logic in order to perform a quote/buy operation to retrieve a meaningful fee. But the fee can be very different for buy and sell operation.
So for now I only increased our minimum value for CowSwap to $20 which should not bother the user too much given fees are commonly $1 - $10. Maybe we can create a separate issue to find a more robust way of estimating fee / calculating a minimum ?

@0xdef1cafe I was finally able to reproduce this issue This occurs in getCowSwapTradeQuote.ts (where quote api is already used) when CowSwap expects a fee greater than $10 (which is our minimum input value when lower value is provided by UX / the user). This is only occurring with quote api when we are performing a sell operation, so the code in this PR where I am performing a buy is not at fault I think.
I have tried changing getCowSwapMinMax.ts logic in order to perform a quote/buy operation to retrieve a meaningful fee. But the fee can be very different for buy and sell operation. So for now I only increased our minimum value for CowSwap to $20 which should not bother the user too much given fees are commonly $1 - $10. Maybe we can create a separate issue to find a more robust way of estimating fee / calculating a minimum ?

@shapeshift/product FYI

Thanks! This sounds like a good approach. When I look at the trade activity from 0x there are only a few trades that are for very small amounts, and I'd assume those are our test trades. I think a $20 minimum is fine for cowswap.

with a rebase and a link locally this is behaving fine, i'm conceptually ok too.


Tanspose and rortate matrix

💥 Proposal
Tranposing and rotating matrix are often required and these have some good tricks which are easy to use.
Have you read the Contributing Guidelines on Pull Requests?
(Write your answer here.)

Can I work on this issue?

Can I work on this issue in Java under GSSoC'21?

Can I work on this issue in C++ in GSSoC'21?

can I work on this issue.

/assign

/assign


View not present in JSON response from DAC

[ ] file bug somewhere about this

Cool Project, learned a lot looking through the code.
android.view.View (if I'm not completely blind) is not explicitly listed in the server response (only the subclasses of android.view.View).
Checked out Roman's extension and it is listing android.view.View. Hadn't time to look further into it - hope this helps somehow.

Hah! You're right. I guess i'll have to figure out where to send that bug tomorrow...
Roman's uses an old source that no longer exists. And actually since then he's merged in a listing that is produced by this project that will also lack View.

Fixed by #156's fix.


fix for optional parameters

when only the second or third optional parameter is used during a JsonRequest, the JsonException "invalid parameters" was triggerd
now fixed => place of optional parameter in declaration of JsonRpcMethod doesn't matter anymore

is this useful for the project?

Hi, @HoMS1987 This does look like it may be useful. How would I reproduce the issue? I need to have tests for what we are fixing here.

@HoMS1987  There are some tests for optional parameters here: https://github.com/Astn/JSON-RPC.NET/blob/master/AustinHarris.JsonRpcTestN/Test.cs#L1074
Could you add one that demonstrates he issue?

The method where the error occured was similar to this:
    [JsonRpcMethod]
    private string TestDifferentOptionalParameters(string uid, string location = null, List<float> traces = null, List<float> wavelengths = null)
    {
        return "this is the requested measurement";
    }

The test cases would be like:
[Test()]
public void TestDifferentOptionalParametersNamedWorking()
{
string request = @"{method:'TestDifferentOptionalParameters',params:{location:'loc1', uid:'abc123', wavelengths: [0.0], traces: [0.0]},id:1";
string expectedResult = "{"jsonrpc":"2.0","result":"this is the requested measurement","id":1}";
var result = JsonRpcProcessor.Process(request);
result.Wait();
Assert.IsFalse(result.Result.Contains("error"));
Assert.AreEqual(expectedResult, result.Result);
}
[Test()]
public void TestDifferentOptionalParametersNamedNotWorking()
{
string request = @"{method:'TestDifferentOptionalParameters',params:{location:'loc1', uid:'abc123', wavelengths: [0.0]},id:1";
string expectedResult = "{"jsonrpc":"2.0","result":"this is the requested measurement","id":1}";
var result = JsonRpcProcessor.Process(request);
result.Wait();
Assert.IsFalse(result.Result.Contains("error"));
Assert.AreEqual(expectedResult, result.Result);
}

The problem is, I have several optional datatypes. The params of the request don't have the same order like in the method. In my case it's not working when I get the first and third optional parameter, the second I don't get.
When I remember correct (the pull request is some months old^^) it's because in C# when you have a method with optional parameters, you can't just call it with the first and third optional parameter. It depends on the order of the implementation of the method. So if the json request only has the first and third optional parameter you automatically have to add the default value for the second optional parameter. and that's what I did in the pull request.

Gotcha, I'll check it out. Thanks for the PR!

There were a few tests covering some edge cases that were not passing with this solution, so I had to take a slightly different approach to the problem to keep all the tests passing.
See PR #119
Again thanks for all your work on this issue!


Support HDR

one of the obvious HDR images for testing
https://share.icloud.com/photos/0e9M35xLvJC2mv5cNfwRswR6g

@muukii Sorry, I'm late !
I'm not sure we want to expand to HDR without explicit user support: if their pipeline does not supports HDR, it's better to use only SDR

@ntnmrndn
right. As a photo editor, the user can always switch using HDR or SDR. like Photomator and Lightroom.


Update readme

I'm not using any more distill, all the blog have been built with quarto.

ref #55


Removed console.logs from app/scripts.babel/contentscript.js file

Removed console.logs from app/scripts.babel/contentscript.js file

Looks good! Thanks for the pr!


ImageCacheBase.AugmentSettings not thread safe, crashing bug.

https://github.com/JimBobSquarePants/ImageProcessor/blob/bc14ee22b3bbb32f710290147673aa97fc6ab0f5/src/ImageProcessor.Web/Caching/ImageCacheBase.cs#L67
Hi Jim,
The method ImageCacheBase.AugmentSettings() is protected virtual method designed to be overridden in custom cache implementations. However, this method is operating on a shared Dictionary<string, string> object taken from ImageProcessorConfiguration.Instance.ImageCacheSettings.
This isn't thread safe when the constructor for a cache is run by two threads and one thread is updating the dictionary while the other thread is looking-up/enumerating on it.
Refer: https://blogs.msdn.microsoft.com/tess/2009/12/21/high-cpu-in-net-app-using-a-static-generic-dictionary/

I think we'll have to simply lock around this when setting as I can't change the dictionary type without introducing a breaking change.


Updated return schema for openapi definitions

Fixes issue with python client not returning any value from http requests.
What does this PR do?
Changed the return schema for some HTTP functions from application/json: {} to
application/json:
    schema:
        type: object

This is a temporary fix. Eventually these functions will need actual return schemas specified. However currently there are no return object schemas specified in the standard so this will unblock the testing PR #39. A new issue has been opened to address the return schema issue #43.
Checklists
Change log

[ ] The CHANGELOG has been updated, or
[x] This PR does not include user-facing changes and doesn't require a CHANGELOG update

Test coverage

[ ] This PR includes new unit and integration tests to go with the code changes, or
[x] The changes in this PR do not require tests

Documentation

[ ] Docs (e.g. READMEs) were updated in this PR, and/or there is a follow-on issue to update docs, or
[x] This PR does not require updating any documentation

LGTM as well, after a rebase against main I can merge this for you.

LGTM as well, after a rebase against main I can merge this for you.

@john-odonnell Should be all set now!


Issue to deploy KMMO using commit 30925efd6efa4806d8ff9f043a7e08abb7661647

The latest commit 30925efd6efa4806d8ff9f043a7e08abb7661647 is having the above error while deploying KMMO on OCP. The commit prior to this one (74bfa7f51c19512d38557cf224f3000e67eb6a0c) does not have this issue.
[hershpa@jfz1r09h07 kernel-module-management]$ oc apply -k config/default
error: accumulating resources: accumulation err='accumulating resources from '../crd': '/home/hershpa/kernel-module-management/config/crd' must resolve to a file': recursed accumulation of path '/home/hershpa/kernel-module-management/config/crd': accumulating resources: accumulation err='accumulating resources from 'bases/kmm.sigs.k8s.io_preflightvalidations.yaml': yaml: line 24: could not find expected ':'': got file 'kmm.sigs.k8s.io_preflightvalidations.yaml', but '/home/hershpa/kernel-module-management/config/crd/bases/kmm.sigs.k8s.io_preflightvalidations.yaml' must be a directory to be a root

Yes it did, thanks @qbarrand!


Make STATE, LATEST, and HERE statically initialized (saves 8 bytes).

This doesn't actually preserve the existing functionality — STATE gets initialized in exec so that if the user errors, it doesn't get stuck in compilation mode (for example).


iOS ARM 64 Build Architecture (App Store Required) causes text to truncate

Debug Build....

Release / App Store Build...

Weird.... Any thoughts on this?

After further testing it seems that having the supported archs set to arm7 + arm64 is what is causing this issue. If i set the supported archs to just "arm7" the truncation seems to disappear. Hmmm....

Should also note that this was tested on a iphone 6 plus

No idea.  I don't even know where to start with this one

Lol no clue either. Same bug exists in the other Xamarin plugin that does just toasts too. Could be a xam bug or just a forms bug (or maybes project template) I will download your source and try some setting changes to see if I can find a fix tomorrow. The fact that this happens in multiple plugins is interesting though. I'll make a couple test projects with current templates tomorrow to see if I can narrow it more. By the way appreciate the quick feedback and releases, flipped my production projects to his because of that.
Cheers
Sent from my iPhone

On Aug 12, 2015, at 7:49 PM, Allan Ritchie<EMAIL_ADDRESS>wrote:
No idea. I don't even know where to start with this one
—
Reply to this email directly or view it on GitHub.

Ok looks like I got this one figured out...
The problem does only exist when selecting a build architecture that includes x64.
When targeting x64 the methods that use NSString.DrawString need to be converted to the non-deprecated extension methods and then the truncation disappears.
To Fix.
In Acr.UserDialogs.iOS.MessageBar.Messageview.Draw
Change.
Title.DrawString (titleRectangle, TitleFont, UILineBreakMode.TailTruncation, UITextAlignment.Left);
to
Title.DrawString(titleRectangle, new UIStringAttributes { Font = TitleFont, ForegroundColor = TitleColor });
and also
Description.DrawString (descriptionRectangle, DescriptionFont, UILineBreakMode.TailTruncation, UITextAlignment.Left);
to
Description.DrawString(descriptionRectangle, new UIStringAttributes { Font = DescriptionFont, ForegroundColor = DescriptionColor });
Perhaps this has to do with Unified API.  See
http://developer.xamarin.com/guides/cross-platform/macios/updating-tips/
Objective-C category methods are now generated as extension methods in the Unified API. For example, code that previously used UIView.DrawString would now reference NSString.DrawString in the Unified API.
Also my test project .......
https://github.com/highplains/ToastTest

Thanks for the PR.  I'm going to have to decline the null icon because it prevents the default icons.  I'll look into this for a future release though


Focus on prompt line

If you click, for example, a minimize buttom, you lose focus on prompt line. So you have to click on prompt line to write again. I think prompt line should be focus all the time or mostly. Click an empty space of main panel, should focus prompt line. Maybe keypress event too.
These are only suggestions. I hope they help you. Mancy is great!

Thanks. I'll incorporate it in version 2. Some of your suggestions are already done but are not ready for release. Wait for 3 weeks :smile:

I've tried v2 branch and looks good!

I tried it on version 2 and it still loses focus all the time

@georgejecook Yes. We can track focus issue here.

yes. sorry about the dupe.

@georgejecook No problem :smile:

Only feasible solution is to make sure to focus active prompt

After every command execution
on window getting focus
Missed something!!! :microscope:

Focusing when

clicking off the prompt (selecting data from main area is impossible if we keep the focus off )
minimise/close command output (if we have sufficient data in main window, every minimise/close action scrolls window down to active prompt)

are invalid

Currently the window lose the prompt cursor all the time:

specially in the new notebook mode!


Update HangfireComposer.cs

Added DummyAuthorizationFilter, this should allow the hangfire dashboard to load when not in localhost context

Oh I didn't get notifications for contributions here @Axendo - apologies that I didn't reply!
This issue has been fixed in a different way in #9 now but thanks for the PR! 👍
I'll release a new version later today that also fully works on Cloud.


Add Google-Certificates-Bridge.

This showed up in some logs for a Google Cloud-hosted site while creating HTTPS certificates. It's used for domain verification under the RFC 8555 protocol.

Thanks @JBYoshi

Thanks @JBYoshi


Sift force-upgrades play-services to 11.0.0

Here's what happens when I try to upgrade to sift-android 0.9.2:

For reference, this is what I'm currently pinning play services to:
  ext.play_services_version = '10.2.1'

Relevant section of the ./gradlew dependencies output from my app:
+--- com.siftscience:sift-android:0.9.2
|    +--- com.fasterxml.jackson.core:jackson-core:2.3.3
|    +--- com.fasterxml.jackson.core:jackson-databind:2.3.3
|    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.3.0 -> 2.3.3
|    |    \--- com.fasterxml.jackson.core:jackson-core:2.3.3
|    +--- com.fasterxml.jackson.core:jackson-annotations:2.3.3
|    +--- javax.validation:validation-api:1.1.0.Final
|    +--- javax.annotation:javax.annotation-api:1.2
|    +--- com.google.guava:guava:19.0 -> 20.0
|    +--- com.squareup.okhttp3:okhttp:3.4.1 -> 3.4.2
|    |    \--- com.squareup.okio:okio:1.9.0 -> 1.11.0
|    +--- org.apache.commons:commons-lang3:3.5
|    +--- com.google.android.gms:play-services-base:[9.8.0,) -> 11.0.0 (*)
|    \--- com.google.android.gms:play-services-location:[9.8.0,) -> 11.0.0 (*)

It looks like this was an intentional change in 0ca2337e78aa18752aaf563c680309b3c176b430 but I'd argue it's a mistake.  If you specify 9.8.0 in your library, and I specify 10.2.1 in my app, it'll seamlessly use 10.2.1 for both.  If you specify [9.8.0,) it apparently forces everybody up to the latest (which is a notoriously bad practice on Android).

I'll get around this for now by using a resolutionStrategy, but that's really unfortunate.
a CHANGELOG.md would be great so figuring out this sort of thing is easier in the future.

Ah, I can change this back @edenman . There was some a version mismatch which was causing an NPE for customers that were importing an older play-services version.

For context, it was something to this effect:
java.lang.AbstractMethodError: abstract method "com.google.android.gms.common.api.Api$zze com.google.android.gms.common.api.Api$zza.zza(android.content.Context, android.os.Looper, com.google.android.gms.common.internal.zzg, java.lang.Object, com.google.android.gms.common.api.GoogleApiClient$ConnectionCallbacks, com.google.android.gms.common.api.GoogleApiClient$OnConnectionFailedListener)"
at com.google.android.gms.common.api.GoogleApiClient$Builder.zza(Unknown Source)
at com.google.android.gms.common.api.GoogleApiClient$Builder.zzuQ(Unknown Source)
at com.google.android.gms.common.api.GoogleApiClient$Builder.build(Unknown Source)
at siftscience.android.AppStateCollector.(AppStateCollector.java:62)
at siftscience.android.Sift.open(Sift.java:57)
at siftscience.android.Sift.open(Sift.java:46)

Gotcha.  Yeah, if you guys need 9.8.0, just refer to that and it should work fine.

I think it was a version discrepancy specifically between an old version of play-services-base and play-services-location:9.8.0 that was causing the NPE. I guess instead of coercing the version we can ask customers to bump their play-services-base version to at least 9.8.0 if they're using our SDK. Thanks again for the feedback!

this has been addressed by v0.9.3

Thanks @garylee1 !


Importing always returns undefined

Hey there!
Firstly, thank you for creating and actively maintaining this package. I am very excited to use it!
Unfortunately, I am getting undefined whenever I try to import from react-native-bluetooth-classic.
Code ran
import RNBluetoothClassic, {
  BTEvents,
  BTCharsets,
} from 'react-native-bluetooth-classic';

const MyComponent = () => {
  console.log(RNBluetoothClassic.isEnabled());
  return (
    <View />
  );
};

Result
Unhandled JS Exception: TypeError: Cannot read property 'isEnabled' of undefined

Note that

Importing the file directly from node_modules also yields the same error
Directly console.logging RNBluetoothClassic, BTEvents, and BTCharsets all yield undefined
Manually linking with Cocoapods yields the same error

Versions
Platform: iOS
React native: 0.61.5
I also used yarn add instead of npm install, not sure if it makes a difference, but I can't use npm install for other reasons.

Is the Bluetooth example app working?

Hold on lemme give it a try

I'm getting this error with the example app
Fatal error: Unexpectedly found nil while unwrapping an Optional value: file /Users/zames/Development/react-native-bluetooth-classic/ios/RNBluetoothClassic.swift, line 53
2020-02-03 07:00:05.274862+0800 BluetoothClassicExample[356:42273] Fatal error: Unexpectedly found nil while unwrapping an Optional value: file /Users/zames/Development/react-native-bluetooth-classic/ios/RNBluetoothClassic.swift, line 53

I tried both npm install and yarn add this time and they're both giving the same errors.
The build succeeds but I only see a blank screen on the device (iPad) after the splash screen.

Have you added in your mfi protocols for the device you're using? There is info on the example Readme on how to add it (I think).
Should be a protocol-strings-example.plist you need to use.

Hey thank you so much, adding the plist tag fixed the problem :)
(It's not in the readme, you should probably add it in too !)
Excited to try the package out, thank you again!

Right on. I'll throw it into both Readmes next time I fire up the project.

thank for your asking, for who want to know what things we have to add:
	<key>UISupportedExternalAccessoryProtocols</key>
  <array>
    <string>com.apple.m1</string>
  </array>
	<key>NSBluetoothAlwaysUsageDescription</key>
	<string>Access bluetooth device over serial connection to document connection features</string>

It's not in the readme, but it's literally the second thing on the document page
https://www.kenjdavidson.com/react-native-bluetooth-classic/ios/#mfi-protocols

Although my app supports both Android and iOS, I (for now) only support Bluetooth Classic on Android.
To prevent the "found nil" Fatal Error I currently have to define an empty array:
<key>UISupportedExternalAccessoryProtocols</key>
        <array>
        </array>

Would be nice if that wouldn't be required.

It's a requirement for mfi.
You can use disable the autoload of native modules by updating your configuration, there is documentation on the react native site. Lookup autolaoding.
Otherwise I feel like adding an empty list is a satisfactory way to resolve the issue.
I'll update the docs.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Hans Bouwmeester @.>
Sent: Saturday, August 21, 2021 3:43:02 PM
To: kenjdavidson/react-native-bluetooth-classic @.>
Cc: Ken Davidson @.>; Comment @.>
Subject: Re: [kenjdavidson/react-native-bluetooth-classic] Importing always returns undefined (#38)
Although my app supports both Android and iOS, I (for now) only support Bluetooth Classic on Android.
To prevent the "found nil" Fatal Error I currently have to define an empty array:
UISupportedExternalAccessoryProtocols

Would be nice if that wouldn't be required.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkenjdavidson%2Freact-native-bluetooth-classic%2Fissues%2F38%23issuecomment-903167112&data=04|01||b5d521589c94484ac3c508d964dbe3d2|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637651717844471444|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Bxn2LiXvmSZ%2Bo9poGzEiWpd1LyiWE3ScNOBNfFGdXSQ%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABPMJL6BDJRAE67PFS5NMS3T576UNANCNFSM4KO4TLMA&data=04|01||b5d521589c94484ac3c508d964dbe3d2|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637651717844471444|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=NKqKwaW7NjLgdmeDuo7K%2FIyDovx0vnrv%2BqjMK2bcAb0%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||b5d521589c94484ac3c508d964dbe3d2|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637651717844481436|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=cju23aJccCY%2BlPVfmvVglFe94DsL%2BiVLRZB2JL8uIIQ%3D&reserved=0 or Androidhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01||b5d521589c94484ac3c508d964dbe3d2|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637651717844481436|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=014XTDQK4PaB5b7FX8VpCPjJvPAXJOtn8KZ35hWcrQE%3D&reserved=0.


AuthPolicy top-level conditions based on CEL only

Removes from the AuthPolicy the deprecated selector, operator, value user-defined top-level conditions, in favour of using CEL predicates for top-level conditions only.
Apply to the AuthPolicy's user-defined top-level conditions the same behaviour as the RateLimitPolicy when merging policies together – i.e. the entire set of conditions treated as one single atomic rule of the policy.
No longer move AuthPolicy's user-defined top-level conditions to the Authorino AuthConfigs, since these conditions are evaluated in the wasm module.
Side-effect: drop support for named patterns for user-defined top-level conditions in the AuthPolicy; they can still be used for rule-level conditions though.

Verification steps
make local-setup

kubectl -n kuadrant-system apply -f - <<EOF
apiVersion: kuadrant.io/v1beta1
kind: Kuadrant
metadata:
  name: kuadrant
spec: {}
EOF

kubectl apply -f examples/toystore/toystore.yaml

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: toystore
spec:
  parentRefs:
  - name: kuadrant-ingressgateway
    namespace: gateway-system
  rules:
  - backendRefs:
    - name: toystore
      port: 80
EOF

Create a couple policies:
kubectl apply -f - <<EOF
apiVersion: kuadrant.io/v1beta3
kind: RateLimitPolicy
metadata:
  name: toystore
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: toystore
  when:
    - predicate: request.size > 1024
  limits:
    "create-toy":
      rates:
      - limit: 5
        window: 10s
      when:
      - predicate: "request.url_path != '/admin'"
---
apiVersion: kuadrant.io/v1beta3
kind: AuthPolicy
metadata:
  name: toystore
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: toystore
  when:
    - predicate: request.size > 1024
  rules:
    authentication:
      "anonymous":
        anonymous: {}
        when:
        - predicate: "request.url_path != '/anonymous'"
EOF

Check the wasm config: (The sets of top-level conditions of each policy go straight into the predicates of the action in the wasm config.)
kubectl get wasmplugin/kuadrant-kuadrant-ingressgateway -n gateway-system -o yaml

Expected output
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: kuadrant-kuadrant-ingressgateway
  namespace: gateway-system
  …
spec:
  phase: STATS
  pluginConfig:
    actionSets:
    - actions:
      - predicates:
        - request.size > 1024
        scope: e2db39952dd3bc72e152330a2eb15abbd9675c7ac6b54a1a292f07f25f09f138
        service: auth-service
      - data:
        - expression:
            key: limit.create_toy__fb82c51a
            value: "1"
        predicates:
        - request.size > 1024
        - request.url_path != '/admin'
        scope: default/toystore
        service: ratelimit-service
      name: 21cb3adc608c09a360d62a03fd1afd7cc6f8720999a51d7916927fff26a34ef8
      routeRuleConditions:
        hostnames:
        - '*'
        predicates:
        - request.url_path.startsWith('/')
    services:
      auth-service:
        endpoint: kuadrant-auth-service
        failureMode: deny
        type: auth
      ratelimit-service:
        endpoint: kuadrant-ratelimit-service
        failureMode: allow
        type: ratelimit
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: kuadrant-ingressgateway
  url: oci://quay.io/kuadrant/wasm-shim:latest

Create a default merge policy:
kubectl apply -n gateway-system -f - <<EOF
apiVersion: kuadrant.io/v1beta3
kind: AuthPolicy
metadata:
  name: gw-auth
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: kuadrant-ingressgateway
  defaults:
    strategy: merge
    when:
      - predicate: request.size > 2048
      - predicate: |
          !source.ip.matches("127\.0\.0\.\d+")
    rules:
      authorization:
        "deny-all":
          opa:
            rego: allow = false
EOF

Check the wasm config: (The set of conditions from the most specific policy wins.)
kubectl get wasmplugin/kuadrant-kuadrant-ingressgateway -n gateway-system -o yaml

Expected output
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: kuadrant-kuadrant-ingressgateway
  namespace: gateway-system
  …
spec:
  phase: STATS
  pluginConfig:
    actionSets:
    - actions:
      - predicates:
        - request.size > 1024
        scope: e2db39952dd3bc72e152330a2eb15abbd9675c7ac6b54a1a292f07f25f09f138
        service: auth-service
      - data:
        - expression:
            key: limit.create_toy__fb82c51a
            value: "1"
        predicates:
        - request.size > 1024
        - request.url_path != '/admin'
        scope: default/toystore
        service: ratelimit-service
      name: 21cb3adc608c09a360d62a03fd1afd7cc6f8720999a51d7916927fff26a34ef8
      routeRuleConditions:
        hostnames:
        - '*'
        predicates:
        - request.url_path.startsWith('/')
    services:
      auth-service:
        endpoint: kuadrant-auth-service
        failureMode: deny
        type: auth
      ratelimit-service:
        endpoint: kuadrant-ratelimit-service
        failureMode: allow
        type: ratelimit
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: kuadrant-ingressgateway
  url: oci://quay.io/kuadrant/wasm-shim:latest

Create an override merge policy:
kubectl apply -n gateway-system -f - <<EOF
apiVersion: kuadrant.io/v1beta3
kind: AuthPolicy
metadata:
  name: gw-auth
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: kuadrant-ingressgateway
  overrides:
    strategy: merge
    when:
      - predicate: request.size > 2048
      - predicate: |
          !source.ip.matches("127\.0\.0\.\d+")
    rules:
      authorization:
        "deny-all":
          opa:
            rego: allow = false
EOF

Check the wasm config: (The set of conditions from the least specific policy wins.)
kubectl get wasmplugin/kuadrant-kuadrant-ingressgateway -n gateway-system -o yaml

Expected output
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: kuadrant-kuadrant-ingressgateway
  namespace: gateway-system
  …
spec:
  phase: STATS
  pluginConfig:
    actionSets:
    - actions:
      - predicates:
        - request.size > 2048
        - |
          !source.ip.matches("127\.0\.0\.\d+")
        scope: e2db39952dd3bc72e152330a2eb15abbd9675c7ac6b54a1a292f07f25f09f138
        service: auth-service
      - data:
        - expression:
            key: limit.create_toy__fb82c51a
            value: "1"
        predicates:
        - request.size > 1024
        - request.url_path != '/admin'
        scope: default/toystore
        service: ratelimit-service
      name: 21cb3adc608c09a360d62a03fd1afd7cc6f8720999a51d7916927fff26a34ef8
      routeRuleConditions:
        hostnames:
        - '*'
        predicates:
        - request.url_path.startsWith('/')
    services:
      auth-service:
        endpoint: kuadrant-auth-service
        failureMode: deny
        type: auth
      ratelimit-service:
        endpoint: kuadrant-ratelimit-service
        failureMode: allow
        type: ratelimit
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: kuadrant-ingressgateway
  url: oci://quay.io/kuadrant/wasm-shim:latest

i.e. the entire set of conditions treated as one single atomic rule of the policy.

Confused about that bit

i.e. the entire set of conditions treated as one single atomic rule of the policy.

Confused about that bit… Do you mean that they are all now always ANDed together (i.e what all was iirc) and there is no any anymore?

No, that's not what I meant. This is about merging 2 policies with the merge strategy.
Say 2 AuthPolicies specify respectively sets A and B of when predicates. Before this PR, the merge would yield a set of when predicates A ∪ B. Now, it is going to be A or B.


Handle email when changing user attributes as admin

Previously if the admin modified user properties then user's email address would be deleted.
This change requires a corresponding addition in the Oskari frontend code. I have it here but need to extract it from our own codebase and make a pull request against nls-oskari/oskari

Thanks, we will test and merge this and the fronted counterpart shortly

Thanks.  Tested and merged.


fix(emby): change default value of Accept-Encoding header

Description
An issue with undici throwing an error because the response body was not decompressed properly: https://github.com/nodejs/undici/issues/3762
TypeError: terminated
    at Fetch.onAborted (node:internal/deps/undici/undici:10916:53)
    at Fetch.emit (node:events:518:28)
    at Fetch.emit (node:domain:488:12)
    at Fetch.terminate (node:internal/deps/undici/undici:10102:14)
    at Fetch.fetchParams.controller.resume (node:internal/deps/undici/undici:10893:36)
    at processTicksAndRejections (node:internal/process/task_queues:95:5) {
  [cause]: Error: incorrect header check
      at Zlib.zlibOnError [as onerror] (node:zlib:189:17) {
      errno: -3,
      code: 'Z_DATA_ERROR'
    }
}

This PR forces the Accept-Encoding header to gzip without deflate for Emby.
This undici issue been fixed in undici 6.21, which is only available with Node.js 23.3.0, the current version of Node.js.
We will have to wait for the next Node.js v24 LTS version to remove this patch.
Screenshot (if UI-related)
To-Dos

[x] Successful build pnpm build
[ ] Translation keys pnpm i18n:extract
[ ] Database migration (if required)

:tada: This PR is included in version 2.2.0 :tada:
The release is available on:

v2.2.0
GitHub release

Your semantic-release bot :package::rocket:


refactor(deps): ImagePullPolicy updated in install.go

Signed-off-by: rootxrishabh<EMAIL_ADDRESS>fixes: #307
This lets karmor pull images present locally when installing karmor using the --local flag. This is useful when you want to avoid unnecessary image pulls and speed up pod startup times.

@DelusionalOptimist can we keep this handled once we move to new KubeArmor controller? and Helm not sure what exactly is the roadmap for installation.
@rksharma95 how will this be handled when we have Operator based deployment. Would we need these options in the Operator CRD?

@rksharma95 how will this be handled when we have Operator based deployment. Would we need these options in the Operator CRD?

yes we'll need to handle it separately if we want to have this option in operator based deployment, we would require to add this option in operator crd.

Folks, this is what the roadmap to helm looks like - https://github.com/kubearmor/KubeArmor/issues/1256
Please add any other points.

@daemon1024 is this good to merge?

Yep


System Downtime

We are experiencing a system downtime, this is being addressed. The inconvenience is regretted.

We have identified the issue and working on a fix.

The impact was due to an unexpected burst of traffic from our third-party messaging channels, which impacted the performance of our database and caching layer.  This led to a service outage for many of our cloud customers.
We have identified the bottlenecks and have applied upgrades to avoid further impact. We will be working on further reinforcements to prevent future occurrences.


Fix layoutSubviews error — pod update

i don't see any change beside the version number changed from 1.2.1 to 1.2.2 in file NMRangeSlider.podspec line 3 and 9. can you add your changes?

I think its just a pump in the pod spec after the last pull-request that fixed a issue with the layoutSubviews,
m4r is that correct?

It is! :)
Sent from my iPhone

On 14 Mar 2015, at 03:42, Murray Hughes<EMAIL_ADDRESS>wrote:
I think its just a pump in the pod spec after the last pull-request that fixed a issue with the layoutSubviews,
m4r is that correct?
—
Reply to this email directly or view it on GitHub.


NTP sync test returns that we are not synced in the first few sec of deploying ova, leading to unneccecery alert.

Environment info

Version: 2.0.0-a6ac935
Deployment: ESX
Customer: QA

Actual behavior

When deploying the ova on ESX we get the following alert immediately after we create the system: "Local server time is not synchronized with NTP Server, check NTP server configuration"

Expected behavior

This Alert should not be prompt in the first few min

Steps to reproduce

Deploy the OVA in the ESX

No longer relevant due to OVA deployment support removal


Shallow and --depth clones

pygit2 doesn't support clones with --depth option or shallow clones, https://github.com/libgit2/libgit2/issues/3058
It may not make sense to completely remove the git client dependency.

shallow clones are now supported in libgit2:
https://github.com/libgit2/libgit2/pull/6557
https://github.com/libgit2/libgit2/pull/6396


Buffer Factory: Add configurability of BufferFactory.

We can now set the minimum account size to track. This will be a PR against upstream once the  dependent PR it builds upon is merged.
Signed-off-by: Kevin Baichoo<EMAIL_ADDRESS>Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes: TODO
Platform Specific Features:

This builds on top of https://github.com/envoyproxy/envoy/pull/17093. Since that's not yet merged I can't make an upstream PR on this, yet. Any initial feedback on this @antoniovicente

envoyproxy#17093 is nearing merge.  I recommend you look into some other things like implementation of accounts for H1 and H3 while this PR is blocked on review.

I'm finishing up tests for the final PR which will include the Overload Manager leveraging this mechanisms fully for H2

That sounds great.

Closing this, made upstream PR: https://github.com/envoyproxy/envoy/pull/17562


Add cross chain sync transaction logic

we need to add:

transaction flow
syncing process update in background
notification about sync process finish

design: ?

@alter-eggo did you not do this already?


[T4A3][T15-A2] Chankyu Oh

Ready for Review

@chankyuoh
I think you named the team wrongly.

@chankyuoh
Some comments added. Please close the PR after reading comments.


Implement message components

https://discord.com/developers/docs/interactions/message-components
This must be implemented in a way that is extendable to further components without creating breaking changes

This has been done and is currently being blocked from PR by #577


Possible memory leak with nuxt-link and/or router-link

Version
v2.10.2
Reproduction link
https://codesandbox.io/s/github/slidenerd/nuxt_child_slow_bug_demo
Steps to reproduce
Run the codesandbox demo
Click on an item in the list on the left pane
try scrolling down immediately, the browser has frozen
The url does not change immediately
try clicking multiple items and scroll up and down and you ll observe the LAG

What is expected ?
The item gets selected immediately. The scroll does not lag, On selecting the child view the url changes rapidly. The app should not FREEZE.
What is actually happening?
In the build version, the app freezes depending on how many items you have, on the dev version, it crashes the browser completely.
Additional comments?
I am trying to build a list detail view with a very simple setup
I have a list on the left pane with 5000 items. Feel free to change the numbers up and down
Clicking on an item on the left side, changes the content of the nuxt-child on the right as per the nested routes demo by official nuxt repo
I am using a key on the child route and no-prefetch and it still lags like anything
The dev version is unrunnable , the build version freezes quite a bit
Some suggestions on how to fix this would be super appreciated

If I am not mistaken, I would need to use the vue-webpack setup via vue-cli to set the same example up, but that would be SPA would it not while this is SSR

It doesnt matter about SSR, since your problem happens on client. And you dont really need even vue cli, you can use cdn version  or via vue-cli, it doesnt really matter.
Also, does it happen in production build or only in dev?

Here is the plain Vue version, it is also slow but the nuxt version literally crashes the browser, I have kept the same number of items 5000

The difference is definitely noticeable, yes.

I have a page which has many <nuxt-link>s,. The below is vue-tools performance data when I navigate  the router.

And, if these <nuxt-link>s are removed from the page, the JS evaluation time will reduce distinctly. By the way, I use ssr mode.

experienced the same as @Alex1990 ... is this being investigated?

Em seg, 6 de jan de 2020 12:25, Max<EMAIL_ADDRESS>escreveu:

experienced the same as @Alex1990 https://github.com/Alex1990 ... is
this being investigated?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nuxt/nuxt.js/issues/6669?email_source=notifications&email_token=AAMOXQDLEMEANCMB3MS4SALQ4NEM5A5CNFSM4JKXE322YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFYSXQ#issuecomment-571181406,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMOXQBWBGKUALP5LROIS4LQ4NEM5ANCNFSM4JKXE32Q
.

First thing that comes to my mind is the intersection observer registered for each link that could influence the perf. But that's just an educated guess at the moment.

This is a problem for me for a few months. Any workaround except switching to the good old ?

Any update or is it confirmed to be a issue with any of the dependencies mentioned in this thread?
Also experiencing this issue and need urgent workaround.

Performance test after navigating to 2 pages in my app.
Using 2.11.0 SSR

I am still having this breaking issue as well. I disabled SEO on i18n and that helped a bit, but still crashing out of memory after some time

I guess it is an implementation issue and not a framework bug since it would be a major issue for everyone.
Now I'm stuck with a giant Nuxt app with <a> tags :expressionless:
Any idea on how to troubleshoot this? @Atinux @pi0 @manniL

After several weeks into it, I am started to be convinced it is a framework bug, even though the implementation setup might trigger it.
Right now my biggest indication is that my npm run dev crashes every 10 minutes or so due to memory overload. If I open multiple browser tabs, the memory overload and resulting crash comes much more quickly. Do you see the same issue with multiple browser tabs to same app?

Please run yarn upgrade to make sure vue-meta v2.3.3 is installed. Recently a memory leak was fixed in vue-meta, maybe thats related to this issue.

Just upgraded all packages npm update and again after 10 minutes the dev environment crashes with memory overload.

Just upgraded all packages npm update and again after 10 minutes the dev environment crashes with memory overload.

Have you seen if it updated vue-meta to v2.3.3 ? I tried an npm update and it didn't get the new version. I will try to force the version later and update this thread with my results.

@Chrisimir  good one! npm list | grep vue-meta gave me :
│ │ │ ├─┬<EMAIL_ADDRESS>│ │ │ ├──<EMAIL_ADDRESS>deduped

So it indeed did not upgrade... So I will keep posted how you achieve ))

It was vue-meta that was to blame in my case :tada:
After updating to 2.3.3, no crash and fast routing.
How I did it:

Deleted node_modules folder
Deleted package-lock.json
npm i

I'm sure there is a better way of forcing an update, but this worked for me, my vue-meta would not update until I deleted the files. Hope this works for you @tvld !

Works in my case with vue-meta 2.3.3 again :) thanks!

Did not want to cheer too soon, but it seems it's solved for me as well, so far npm run dev did not crash again for me :tada:

I've been running for a couple of hours too now - no crash.

Bummer... I got the same issue, crash on out of memory. But it's taking longer so at least some progress.... :thinking:

@tvld Do you still experience it only has issues when you use route.params or does the memory consumption rise with every type of link?
Have you played around with link prefetching to see if there is an improvement?

@Chrisimir  I've just spent half an hour refreshing pages on our production (www.bligson.com), switching between pages. Before vue-meta 2.3.3 the memory size would grow with 5MB going back and forth between two pages. Now it stays about the same, if I let garbage collection do its work. So that's good.
What I still have though is that de development environment crashes with out of memory. I start to think it is is related to vue-i18n not cleaning up after each reloading of a language file but that's just a hunch  so far. If so, than the issues is not related to this one ...

Even with "nuxt": "^2.12.2" npm run build && npm run start somewhat runs decently (still slower than the plain vue version) but npm run dev completely crashes within seconds of trying to scroll up and down and open a few links

I upgraded my RAM from 12GB to 24GB, and since then I did not have this crash...yet at least...   could this be related?

@tvld i checked the memory consumption yesterday, it was handling promises non stop in one file. I think its getting stuck in some sort of loop.

We are approaching the Nuxt 2 EOL date (June 30, 2024) - see this article for more information. This is advance warning that I'm going to close this issue then, as it's currently marked as a Nuxt 2 related bug.
If it's a critical or security issue, please do comment and let me know, in case it is possible to address it before the EOL date.
If it's a an issue you think is relevant for Nuxt 3, please feel free to open a fresh issue (or just comment here so I can update labels, etc.). 🙏
Thank you for your understanding and for your contribution to Nuxt. ❤

It's the day, at last. Nuxt 2 is now marked end-of-life.
My apologies we never got round to resolving this bug in the 2.x branch, but we do have to draw a line somewhere. Again, if you think this is still relevant for Nuxt going forward, please feel free to open a fresh issue (or just comment here so I can update labels, etc.). 🙏


Outlines diverge at certain camera angles with SetOutlineDepth::Flat

I've stumbled across a strange bug where certain camera angles will cause the rendered outline to jump off the object and diverge into the background.
I've created a gist the reproduces the issue. It does not happen with SetOutlineDepth::Real. Changing the model_origin for SetOutlineDepth::Flat does not seem to change the effect, positively or negatively.
Here's are screenshots from the gist which illustrates the problem:
Okay

Diverging

The gist itself is animated to make the issue more clear.
I'm pretty clueless about what could cause this. I would guess that vertices which have fallen out of the camera view are somehow getting reflected inside the GPU, possibly off to infinity, but I have no idea why that would happen. Especially since it seems to happen for Flat but not Real.

This bug is caused by my performing the conversion to NDC space inside the vertex shader. I implemented it that way in order to eliminate variance in the fragment depths (z * w / w != z due to rounding) that was causing Z fighting between entities and their stencils. Unfortunately, as you've discovered, this doesn't work because it breaks the clipping of triangles which are behind the camera.
I think a small constant depth offset in the stencil should provide an alternative solution to the Z fighting so that the vertex shader can use the correct coordinate space. I'm working on it.

Fixed by 0df3735906445a653547b5639479fd8c2ec5b71e.
I'll make a new 0.3.x release soon.

Released 0.3.4.

Thanks for addressing this so quickly!
I thought I should mention, it seems like SetOutlineDepth::Real no longer works with release 0.3.4. That doesn't effect me personally because I only want to use Flat, but I'm sure you didn't intend that outcome.

Oops! Thanks for letting me know. I need to add an example that uses it. I've released 0.3.5 with a fix.


[Bug] error in division method two inconsistent decimalv3 numbers

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
1.2.5
What's Wrong?
select _col0,_col1,_col0/_col1,cast(_col0 as decimalv3(38, 10))/cast(_col1 as decimalv3(38, 10)) from test_20230926 LIMIT 1;
result：
8888.88800000000000000000 | 0.88800000000000 | 1.916004318248527384365848 | 10010.00900900900900
What You Expected?
8888.88800000000000000000 / 0.88800000000000 = 10010.00900900900900
How to Reproduce?
ddl:
CREATE TABLE test_20230926 (
name varchar(65533) NULL,
_col0 decimalv3(38, 20) NULL,
_col1 decimalv3(38, 14) NULL,
_col2 decimalv3(38, 24) NULL
) ENGINE=OLAP
DUPLICATE KEY(name)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(name) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 3",
"in_memory" = "false",
"storage_format" = "V2",
"disable_auto_compaction" = "false"
);
insert into test_20230926 values('f',8888.888,0.888,8.8);
select _col0,_col1,_col0/_col1,cast(_col0 as decimalv3(38, 10))/cast(_col1 as decimalv3(38, 10)) from test_20230926 where name='f';
Anything Else?
no
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

You can upgrade to 1.2.6


HBASE-28929 Set hadoop-three.version in Hadoop 3 backwards compatibil…

…ity tests

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6380/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6380/1/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  6s

Docker mode activated.

-0 :warning:
yetus
0m  2s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s

Maven dependency ordering for branch

_ Patch Compile Tests _

+0 :ok:
mvndep
0m  8s

Maven dependency ordering for patch

_ Other Tests _

2m  9s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6380/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6380

Optional Tests

uname
Linux fb5d8e79726e 5.4.0-195-generic #215-Ubuntu SMP Fri Aug 2 18:28:05 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / f609cd12cecec7f6b1819ad233caf77663038134

Max. process+thread count
39 (vs. ulimit of 30000)

modules
C:  U:

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6380/1/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 32s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 10s

Maven dependency ordering for branch

+1 :green_heart:
spotless
0m 45s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m  4s

Maven dependency ordering for patch

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
spotless
0m 42s

patch has no errors when running spotless:check.

_ Other Tests _

+0 :ok:
asflicense
0m  1s

ASF License check generated no output?

3m  5s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6380/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6380

Optional Tests
dupname asflicense codespell detsecrets shellcheck shelldocs spotless

uname
Linux b3c267f3c73c 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / f609cd12cecec7f6b1819ad233caf77663038134

Max. process+thread count
46 (vs. ulimit of 30000)

modules
C:  U:

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6380/1/console

versions
git=2.34.1 maven=3.9.8 shellcheck=0.8.0

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

That's my understanding, I have no plans to make changes to the Hadoop2 tests.
I believe that Hadoop2 is dead, and I don't expect new minor releases (no new release in 2 years).
At this point I consider Hadoop 2 support more of a keeping our promises thing than something with real world
relevance. The one major HBase on Hadoop 2 holdout I know has started migration more than a year ago, I'd be very surprised if many people were running Hbase 2.5+ on Hadoop 2.
Having said that, I think that we should consider bumping the Hadoop2 version to 2.10.2, as 2.10.1 has several CVEs, but in that case I would just use the old process, and drop support for 2.10.1, instead of testing for both.
If/when we need to extend the backwards compatibility testing to Hbase 2, we can add similar hadoop-two.version cli options, so that we can keep the logic in the Jenkinsfile, instead of Yetus or the nightly script.


Using objects as type for Output in CHECKSUM schema

Current the output property in checksum schema is a list of object each containing a checksum and a field.
checksum: '5227222155343350591'
  field: xt
- checksum: '5223776204015802370'
  field: xu
- checksum: '3524025294143080071'
  field: yt
- checksum: '3533356873625590408'
  field: yu

The problem is when comparing two checksum. Currently we iterating through output list of one checksum and performing a linear search on other checksum output list for each iteration.
I suggest moving to an object
xt: '5227222155343350591'
yt: '3524025294143080071'
yu: '3533356873625590408'

This way we don't have to perform linear search for each iteration, instead it will be a constant time operation. It will also make the checksum file shorter and simpler.

So, it would go from something like:
output:
- checksum: '12345'
  field: xt
- checksum: '54321'
  field: xr
schema_version: 1-0-0

to:
output:
  xr: '54321'
  xt: '12345'
schema_version: 1-0-0


user_data a nil value.

Occasionally get such errors. What might be missing?
Error detected while processing CompleteDone Autocommands for "<buffer=3>":
E5108: Error executing lua ...s/github.com/nvim-lua/completion-nvim/lua/completion.lua:98: attempt to in
dex field 'user_data' (a nil value)

Should be fixed in the latest commit. Please update and check.

yes should be check if it's nil. aha.. I had fix it,But forget send pr.

I normally make sure user_data is not nil when I'm inserting complete_items... But still checking if it's nil is not a big deal:)

Another question , can we trigger signature help when we confirm  like coc?

Not sure what you mean be when we confirm... Feel free to open another PR and elaborate more on it:)


Prevent zero optimizer loading when finetuning a model and using zero_optimization

The proposed change prevents loading zero optimizer checkpoints when finetune=True. It goes along with the recently merged PR #927 to gpt-neox (https://github.com/EleutherAI/gpt-neox/pull/927).

@bentherien -- Please sign the CLA

@Quentin-Anthony I agree, and would greatly appreciate that. Will create and send it soon